100% CPU diagnosis


News: 100% CPU diagnosis

  1. 100% CPU diagnosis (8 messages)

    On the Java Posse mailing list, someone posted a question about a JVM that was eating CPU like candy from a baby.

    Here's the problem from the mailing list:

    I found a java process whose cpu is almost 100% at my notebook.

    Here is the top output:

    6150 root      20   0 1411m 612m  12m R 98.8 15.7  45:49.12

    and the jstack output for thread 6150(0x1806):

    "VM Thread" prio=10 tid=0x0000000040ca9000 nid=0x1806 runnable

    the last is jstat -gc output:

    S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
    64.0   64.0   0.0    0.0   332992.0   0.0     666304.0   73192.5   83968.0 83967.9   6893   17.576 6882  2705.923 2723.499

    Before you read further, take a look at this and see if you can tell what the problem is...

    Now for the solution. Kirk Pepperdine said this:

    YGC (Young gen count) is 6893 and FGCT is 6882 which is a completely ridiculous full GC to GC ratio. As for the times, YGCT is 17.56 where as FGCT is 2705.923 giving a 99.9% Full GC to GC ratio. A normal FGC:GC ratio should be less than 5% and less than 1% is desirable.

    Second observation
    PC is perm gen configured @ 83968 and PU perm gen used at 83967.9
    Diagnosis: Frequent Full GC's due to Perm Gen being full.
    Solution: Increase the size of perm gen using -XX:MaxPermSize.

    Awesome work, Mr. Pepperdine. Kirk is a frequent speaker at conferences, and he does a lot of performance work. If I needed a performance guru, Kirk would be the first person I'd think of.

    Threaded Messages (8)

  2. Nice![ Go to top ]

    Very interesting observation. I´ll take care of this, for now. :)

  3. as an engineering tool[ Go to top ]

    Although not directly related to the notes, there is a tool I recently developed to determine optimal JVM settings.  http://sourceforge.net/projects/hmte/


    Best Regards,



  4. as an engineering tool[ Go to top ]

    I actually want to know how to make my Java program eats up 100% CPU because my programs never get that even though I tried running dummy program that loops it for 10 million times doing something, it just can't go up to 100%, I guess I have a problem in my program and I really want to know because if I know how to do that, I get an understanding of how to leverage multithreads to handle this situation.

  5. hitting 100%[ Go to top ]

    It used to be a lot easier to hit 100% CPU, but with multiple cores and some cores being more equal than others, and with "smarter" JVMs and operating systems, it seems like the whole stack is conspiring to keep your code from gobbling an entire CPU.

    You can do it, though. The benchmark needs to split out the intensive code from the test harness, so that repeated calls from the test harness force JIT optimized compilation (e.g. Hotspot). Also, the code has to "do something" or it may get optimized out altogether. Then figure out how to measure the cores individually, so you can see if you are pegging a particular core.


    Cameron Purdy | Oracle Coherence


  6. 100% CPU diagnosis[ Go to top ]

    It seems very strange that after all the years Java been on the market people still have to spend their time on absolutely non-value added activity of determining what permanent generation size should be.

    Why can not JVM just figure it out itself just like it adjusts size between other generations? Supposedly Azule JVM/Zing does this why can not Oracle do the same or at a minimum tell you what the problem is?

    Same goes for setting heap size - supposedly you have to tune it and create your application to always fit in that tuned limit but there is no direct architectural support in Java to create any such application.

    Let us say one writes a word processor that would deal with documents of wide range of sizes:

    Using C++ one would usually just create object model that represents the whole document and the OS disk swapping mechanism will deal with any excessively sized documents by trading off performance.

    With Java you can not do this since a user will get Out of Memory Error if the document does not fit in the heap. Alternative is to write or acquire intricate object model that would keep only fixed size portion of document in memory and implement its own swapping/transparent loading behind the scenes. So you either sacrifice user experience or productivity/cost - nice choice to be contended with.

    Best of luck,


  7. 100% CPU diagnosis[ Go to top ]

    Well luckily with the upcoming OpenJDK efforts (JDK7 and 8) there's a definite plan to reduce and then get rid of PermGen. It's a step that some will argue is long overdue, but for now I'm happy that it's been given some serious thought :).

  8. Point awarded[ Go to top ]

    "It seems very strange that after all the years Java been on the market people still have to spend their time on absolutely non-value added activity of determining what permanent generation size should be."

  9. 100% CPU diagnosis[ Go to top ]

    Hi ,

    I want to be more educated on Java/J2ee performance improvements.

    Can ypou guide me how to proceed ? are there white papes on java performance.s