tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Laiho <>
Subject Re: Java/Tomcat 5 CPU utilization very high under low load
Date Wed, 28 Jan 2009 18:35:16 GMT
David Wall wrote:
> We are running Tomcat 5.5.27 on Linux 2.6.18-53.1.4.el5xen (Red Hat
> 4.1.2-14) with Java 1.6.0_05 (32 bit) in a Xen virtualization
> environment (not my server, so unsure what version that is).  It has 3
> webapps running, two of ours and Tomcat's manager.
> Normally, when we run 'top', Java and it's related PG 8.3.3 database
> that drives the Tomcat webapps show very low CPU utilization (0-1%) and
> even leave the 'top' listing.  When there is higher user activity, we
> see Java increase to 4-20% utilization, but these are spikes that also
> tend to return to the low utilization shortly after the burst.  We run
> Java with options: -server -Xms2200m -Xmx2200m -XX:MaxPermSize=128m.
> But every so often, Java "goes crazy" and reaches 95-99% CPU
> utilization, and it sticks there, even though there is little Tomcat
> activity.

To me this sounds like the garbage collection kicking in (and not
finding much to throw out).

You should be able to see thread-level elapsed CPU time with
"ps -fLp <tomcat_process_id>". By running this command a few
consecutive times and comparing the results, you should be able
to see if there's a certain single thread that is taking up all
or most of the CPU. Then it'd be a task to match these thread ids
to information from the thread dump.

F.ex. from my toy machine;
$ ps -fLp 7044
tomcat    7044     1  7044  0   40  2008 ?        00:00:12 /usr/lib/jvm/java/bin
tomcat    7044     1  7118  0   40  2008 ?        00:02:58 /usr/lib/jvm/java/bin
tomcat    7044     1  7119  0   40  2008 ?        00:00:00 /usr/lib/jvm/java/bin
tomcat    7044     1  7892  0   40  2008 ?        00:36:26 /usr/lib/jvm/java/bin
... (there are a number of other threads)

Then, at least on my JVM, the thread ids are shown in hexadecimal, so
it's best to convert the "interesting" thread ids to hex; from the above,

... and the thread info from the dump matchind to the above:
"main" prio=1 tid=0x0805cfb8 nid=0x1b84 runnable [0xbfffc000..0xbfffd708]
"VM Thread" prio=1 tid=0x08099f38 nid=0x1bce runnable
"Reference Handler" daemon prio=1 tid=0x0809cae0 nid=0x1bcf in Object.wait() [0xb2519000..0xb2519f20]
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=1 tid=0x083444e0 nid=0x1ed4
waiting on condition [0xb135c000..0xb135cfa0]

In the dump there is also the call stack for each of the threads,
so if it's an application thread that's using CPU, you'll get at least
some glimpse where in the code the time is spent.

The call stack may also contain information about threads being
deadlocked with each other (but this wouldn't lead to high
CPU usage -- instead this would lead to a standstill without
any CPU being used).

I hope these were of any help,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message