CMS Garbage collection eating up processor power

Jon Masamitsu Jon.Masamitsu at Sun.COM
Thu Mar 27 21:56:35 UTC 2008

The default for CMS were set differently because
there was some expectation of a distribution of
mostly very short lived objects or long lived
objects.  That is, that GC was keeping objects
in the survivor spaces needlessly because they
would mostly be promoted into the tenured
generation.  That was changed in jdk6.

Which reminds me that T.K should also increase
the survivor spaces sizes.

Michael Finocchiaro wrote:
> Isn't the default on 1.4.2, 31?
> And on Java5, its 15? In my experience, the default values work fine. I 
> don't mess with either this or the TargetSurvivorRatio anymore because I 
> haven't seen measureable performance differences over the default values 
> on any platform (Solaris, RHEL, Windows, OS X or HP-UX).
> Fino
> Sent from my iPod
> On 27 mars 08, at 21:50, Jon Masamitsu <Jon.Masamitsu at Sun.COM> wrote:
>> To go along with this idea trying to more effectively use
>> the young generation to filter out objects (i.e., lower the
>> amount that gets into the tenured generation), you need to
>> set MaxTenuringThreshold.  Please see
>> Michael Finocchiaro wrote:
>>> I think your Eden is too small (should be 1/4 of -Xmx for CMS and you
>>> are at about 1/9 or 1/10...) and that the CMS is filling up too fast
>>> because to many objects are prematurely aged into Old. If you increase
>>> -Xmn and decrease the SurvivorRatio to 4, how does it behave? I guess it
>>> really depends on the lifespan of your objects. Are you ever getting to
>>> the TenuringThreshold with your objects before they are promoted to Old?
>>> I think you'd need at least -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
>>> and possibly (albeit it is VERY verbose) -XX:+PrintTenuringDistribution
>>> to find out.
>>> Fino
>>> Cheers,
>>> Fino
>>> On Thu, Mar 27, 2008 at 6:39 PM, Jon Masamitsu <Jon.Masamitsu at
>>> <mailto:Jon.Masamitsu at>> wrote:
>>>    Using CMS sometimes needs some tuning (especially
>>>    with the 1.4.2 jdk).  Do you have any gc logs
>>>    (-XX:+PrintGCDetails) so we can see what's happening?
>>>    T.K wrote:
>>>> Hi All,
>>>> We got 5 Sun Web Servers running on Java 1.4.2, and used to use the
>>>> default GC for Tenured space. The problem with that is that it takes
>>>> 60-80 seconds everytime the GC happens, and the latency on the
>>>    site goes
>>>> crazy. So we decided to change it to use the Concurrent Mark Sweep
>>>> Collector on one server to test it out. Here's the setting:
>>>> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xms3G -Xmx3G
>>>    -XX:NewSize=384M
>>>> -XX:MaxNewSize=384M -XX:PermSize=64M -XX:MaxPermSize=64M
>>>> -XX:CMSInitiatingOccupancyFraction=60
>>>> With that setting, the server runs great. But eventually, when the
>>>> server reach a medium load (around 100-200 users), the tenured
>>>    space is
>>>> always around half full, and the CMS collector starts to run
>>>> continuously one after another. It doesn't hurt the application
>>>    for now,
>>>> but it's taking 25% of processing time (we got 4 cpu, so one web
>>>    server
>>>> always keep 1 cpu power). I don't see that much cpu utilization
>>>    on other
>>>> web server that don't have CMS, and they have more users than the one
>>>> with CMS. If we got CMS on all 5 web servers, I'm wondering if
>>>    that will
>>>> crash the server or not.  What should I do to decrease the processor
>>>> utilization caused by GC?
>>>> Also, I'm thinking to use i-CMS on the JVM, and maybe that might slow
>>>> down the CMS and reduce the amount of CPU utilization by CMS. Any
>>>    thought?
>>>> Thanks,
>>>> TK
>>> ------------------------------------------------------------------------
>>>> _______________________________________________
>>>> hotspot-gc-use mailing list
>>>> hotspot-gc-use at
>>>    <mailto:hotspot-gc-use at>
>>>    _______________________________________________
>>>    hotspot-gc-use mailing list
>>>    hotspot-gc-use at 
>>> <mailto:hotspot-gc-use at>
>>> -- 
>>> Michael Finocchiaro
>>> michael.finocchiaro at <mailto:michael.finocchiaro at>
>>> Mobile Telephone: +33 6 67 90 64 39
>>> MSN: le_fino at <mailto:le_fino at>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at
hotspot-gc-use mailing list
hotspot-gc-use at

More information about the hotspot-gc-dev mailing list