Java "JVM Thread" is consuming CPU

[Gabriel Sala]

Our application in HPUX (PA , 4 CPUs) is consuming a lot CPU even in idle state.
The JDK is 1.3.1.08 and OS version is 11
After analyzing with glance and comparing the thread Ids with full thread dump I found that
1. The thread consuming most of the CPU (60%) is "JVM Thread" (as stated in full thread dump) , so we can't use java profiler, because it's internal JVM code, not our... in fact the profiler is showing that "our" (i.e. the application threads were mostly in wait )

2. The consumption is on "User" time, so we can't use tusc

3. According to OS admin, the OS has all the requiered patches (I know, I have to confirm that persanally)

Application details : uses about 100 threads , -Xms256M -Xmx1024M (consumes ~256 M actually) <50 sockets, idle when tested ... ~0 other I/O

Any idea ?

[Steven E. Protter · Accepted solution]

You have blocked most of my usual avenues of investigation.

Java is current, and you say all the patches are in.

I'm curious and can place a tool in your hands to collect more data. Script attached.

SEP

[Steven E. Protter]

Sorry, another idea.

http://www.hp.com/products1/unix/java/java2/hpjtune/index.html

A performance measurement tool. You may have already tried this.

SEP

[Carlo Montanari]

What about garbage collection?
(run application with -verbose:gc and check frequency/duration of GC's)

[Gabriel Sala]

After all, I had to travel to the customer place.

We found :
1. Effectively, not all patches were applied .
The customer uses a "conservative" policy on patch application.

2. A very old version of one of the components, that called gc frequently.
(All the tests were realized with the latest version , thats why we couldnt reproduce the problem)

After we replaced that version of component by the latest one (that is not calling gc), the CPU usage decreased to 1-3% (without applying the OS patches)



Thanks to all !!!

P.S. The last question I have now is : "Why the frequent gc() is increasing CPU usage of JVM Thread , not the thread that is calling gc"...
but, anyway, this question is more theoric, everything is working fine now. :)

[Carlo Montanari]

The gc is done by the JVM, not by the user thread which requested it (and usually it's not requested by an user thread, it's triggered by a low memory condition).
The memory freed or moved by the gc can belong to many other threads, not only to the requestor, so the work is done by JVM itself.
(Not really an immediate answer, I know :))