On 10/06/2013 16:56, André Warnier wrote:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mihamina,
On 6/10/13 7:12 AM, Mihamina Rakotomandimby wrote:
I have one Tomcat instance, which has several applications
(containers)
Note: these are not "containers" (at least not in any spec-recognized
way). Tomcat is the container, the webapps are called "contexts" -- or
just webapps usually.
On my installation, when Tomcat is running, only "java" process
owned by "tomcat" is listed.
When the "java" process gets 100% CPU, I would like to be able to
differentiate which application is it about.
You can only do this by taking a series of thread-dumps (maybe 1 every
5 seconds for 15 or 20 seconds) and comparing them to each other. You
can probably find out which threads are doing a lot of work (because
they are running a lot of code over the time period) and which
applications are being used (because of the content of the stack traces).
Of course, you have to have a way to detect "high" CPU usage (100%
probably isn't good enough) and then trigger these thread dumps, etc.
One solution, for me, is to be able to run one java process per
war under a (pre-created) system user. I would like to keep only
one Tomcat instance.
You can have one of these, but not both. You *can* have a single
Tomcat /installation/ and multiple instances, of course (read the
RUNNING.txt file that comes with the Tomcat bundle under the
"Advanced" section).
Remember: memory is cheap. It's not that costly to run multiple Tomcat
instances. Tomcat requires roughly 12MiB on my system (64-bit with
compressed OOPs) with no web applications deployed into it.
Alternatively, a "cheap" way of getting at least an idea of what
application is using a lot of time :
In a first approximation, I would tend to believe that an application
which uses a lot of CPU time, is also probably slow to respond (to the
user).
That assumption rarely holds. It is usually a sub-set of requests within
an application that are slow and when you do have a problem, everything
is slow.
The best / quickest (and I would say simplest) way to get the correct
answer is as follows:
1. ps -eLf (to show per thread results)
2. Find the thread using all the CPU
3. Take a thread dump of your Tomcat process
4. Match the LWP ID (base 10) from the ps output with the nid field
(base 16) in the thread dump to find a) the offending thread and b)
exactly what it is doing.
There may be slight variations in commands and output format bewteen OS
and JVM vendors but you get the idea.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
