tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Laiho <>
Subject Re: Individual servlet statistics
Date Thu, 26 Jun 2008 18:17:44 GMT
Tyler DeWitt wrote:
>     I was curious if anybody knew of some software that tracked the memory
> and cpu usage of each servlet that was running on a Tomcat instance.  I am
> looking to be able to say "Servlet A is using 2%CPU and 10 mb of heap and
> Servlet B is using 2% CPU and 200 mb of heap."  I need to be able to do this
> because the company I work for uses a Tomcat server running 20 servlets.
> Occasionally, a servlet will begin consuming huge amounts of resources
> (either CPU or memory). 

If it is really occasionally, then a continuous metering might not be
that good; more effective would be to be able to gather data when the
abnormal situation arises.

> Our only diagnostic tool tells us that Tomcat is consuming resources, it
 > does not pinpoint the actual misbehaving servlet.

As for CPU (this depends on platform of course, which you did not
- you can get a thread dump of the JVM, which will (among other
   things) disclose what was running at the time of the thread
- you may be able to see per-thread CPU statistics from the OS
   level (this is the platform-dependent part!), and correlate
   them with the thread information in the thread dump; this should
   give you enough to identify the CPU hog; most of the time when
   I've seen issues with Tomcat eating all of the CPU it has been
   either a servlet (or something called via a servlet) stuck in
   a loop for some oversight in application logic, or alternatively
   it has been the garbage collector trying to survive from
   an application that leaks memory

Then to memory usage issues; my recommendation is YourKit memory
profiler ( YourKit will give you the tools
to take a memory snapshot at the time your application is having
problems with memory usage (or can even take a snapshot by itself
when memory usage exceeds a pre-set threshold). This snapshot can
then be analyzed off-line to find out the object reference graphs
in the running application. A big plus in this way of analyzing
memory issues is the non-intrusiveness - and from that the extremely
low impact (I haven't been able to notice any - something might be
visible if measuring with accurate timing tools) to the runtime
performance (except for the moments when a snapshot is just being
taken; at those point the JVM may freeze completely for a short

No coding, no recompilation required.

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message