Hi again,
I think I've located the Thread that is consuming the CPU, although
I'm none the wiser.
Every time I capture the thread using much higher percentage CPU than
all other threads, it's pointing to '
"VM Thread" prio=5 tid=0xb12f8 nid=0x4 runnable
With no stack trace associated to it, is this common?
when trussing the main Tomcat process it's performing hundreds/thousands of
stat64("<jar file including path>", 0xDBE7EDA8) = 0 against the Jar
files in the directory for each jar contained in the webapp I'm
troubleshooting.
I'm generating the load by sending loads of requests for a single
page, it seems like a lot of stat64's for the same thing that I would
assume should be cached in Tomcat unless specified otherwise?
Anyone seen this type of behaviour?
Many thanks.
Mark.
On 25/07/07, Mark Stevens <[EMAIL PROTECTED]> wrote:
> Thanks very much all for the advice,
>
> I've managed to get my thread dumps nicely formatted side by side in
> HTML using TDAN (Thread Dump Analyzer)
>
> I'll work out how to then get thread ID's using 'ps' and then should
> be in business.
>
> I'm also going to speak with DBA about limiting Oracles(Database)
> memory, and get Tomcat moved from was into RAM, I think this will help
> general performance, but isn't the root cause.
>
>
>
>
> Thanks again,
>
> Mark.
>
>
>
>
> On 25/07/07, Juha Laiho <[EMAIL PROTECTED]> wrote:
> > Mark Stevens wrote:
> > > I don't think we are using sendfile, to be honest, I've had no
> > > involvement in development of the code, I'm just requested to look
> > > after the server.
> > >
> > > I'm going to try and work out how to read thread dumps, hopefully this
> > > will help, I'm finding my X11 connection too slow for J-Profiler to be
> > > usable.
> >
> > Ok, some more details on what to look for (pretty much already
> > said by Charles in an earlier message).
> >
> > When you encounter the CPU hogging situation, run (several times, if
> > needed) such form of "ps" command that shows data on the individual
> > threads. This'll give you the thread ID of the CPU-hungry thread (most
> > possibly there is just one thread in this state), when you look at the
> > CPU time used by thread - one is incrementing, others are not.
> >
> > Then run "kill -QUIT <tomcat_process_id>" to get the thread dump in
> > catalina.out logfile.
> >
> > When you have the thread dump, you'll at least get a name of the thread
> > and the Java method name being executed in the thread which is eating
> > your CPU. This gives, if nothing else, a possibility to see whether
> > the thread is looping in Java library code, application code, or Tomcat
> > server code. A caveat on the data formats; at least on Linux platforms
> > the thread ids from "ps" are in decimal, whereas in Java thread dump
> > they are in hexadecimal, so you'll need to do a dec->hex conversion to
> > the thread id from ps before searching in the thread dump.
> >
> > > Something else I noticed in my Live envrionment is that Oracle is
> > > hogging all the memory and tomcat is being forced into swap.
> >
> > Oracle as in database - or application server? If database, then you'll
> > need to get your DBA people to re-tune Oracle to leave some memory for
> > others as well. If you're the DBA as well, see Oracle documentation on
> > tuning SGA and db buffer cache sizes.
> > --
> > ..Juha
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
