Java threads listed using kill -3 does not contain all threads found using ps -auxww

Hello

We are currently experiencing a problem running ServletExec (java Servlet container) where a process starts hogging the CPU. We end up having to restart the program.

As a Java developer, in these situations you tend to issue "kill -3 <pid>" commands to try to determine the rogue thread. The java VM traps this signal and outputs it's currently executing threads to system error.

In Linux, each java thread is implemented as a process. The rogue process I mentioned above does NOT appear in the "kill -3" stack trace which is very strange.

So I ran a very simple java program that starts a thread and continuously sleeps for 2 seconds and then prints out "Sleeping..". If I issue kill -3 commands against this program and compare against a listing of the threads using ps -auxww the latter contains more 2 threads.

So the "problem" is not a ServletExec issue.

Am I correct in my assumption that all the processes seen using ps -auxww should be visible in the Java stack trace? If not, how can I find out what the rogue java process is doing?

Many thanks for any info.

Environment:

Red Hat release ES 2.1
kernel version 2.4.9-e.62smp
hardware hp ProLiant DL360 G3
java j2sdk1.4.2_09
ServletExec 4.1.1 patch 27

Am I correct in my assumption that all the processes seen using ps -auxww should be visible in the Java stack trace?

You're wrong, not every JVM thread is a Java thread, some are pure C threads.

If not, how can I find out what the rogue java process is doing?

I would use pstack on Solaris, I'm not sure what the equivalent is with Linux, anyway if it's a system thread, there is not that much you can do to control it.
I suspect it to be some garbage collection task, so you can try upgrading the JVM, switching GC algorithm, checking if the real culprit is not a memory leak in your code, ...

Many thanks for the quick response!

After using java for over 6 years there's still more to learn!

We're going to revert back to the vanilla GC algorithm. We were using the Concurrent Mark and Sweep algorithm which has worked fine for us. We're wondering if it is related to our upgrade to Java 1.4.2_09 which we made recently.

BTW, a useful point on the subject of Java garbage collection. It appears that the default value of -XX:NewRatio on Intel/Linux is 32 and not the same as the default value on Sparc/Solaris of 2. Presumably it thinks your running desktop application. It can really adversely affect your GC tuning!

cheers