F.ex. from my toy machine;
$ ps -fLp 7044
UID PID PPID LWP C NLWP STIME TTY TIME CMD
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,
7044=0x1b84
7118=0x1bce
7119=0x1bcf
7892=0x1ed4
... 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.
Thanks for the detailed explanation, Juha. When I get some info, I'll
post back what I find. I've added your 'ps' commands to our checking,
along with the jmap and thread dumps suggested as well. Hopefully
we'll be able to find it.
I was interested to see that it could also be SOAP threads that get in
trouble, since another aspect of this particular deployment is that it
uses the Salesforce SOAP APIs to update data back in Salesforce, so
perhaps it will be something there.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
