Help against CMS old gen fragmentation (was: G1GC success examples (compared to CMS) ?)

[Alexey Ragozin]

Hi Andreas,

Unfortunately -XX:PrintFLSStatistics=<n> is producing too much garbage
in logs making it self impractical for production environment.
Exposing larges heap free chunk size via JMX would be much more useful
for monitoring purposes.

Lack of any way to monitor fragmentation in production is very
unfortunate from operational prospective (especially for 24x7
applications). Fragmentation is building up slowly and if it would be
possible to detect it (size of largest chunk below threshold) ops
could restart JVM gracefully before imminent full GC.

To (other) Andreas

Besides increasing heap size, tweaking PLABs can reduce fragmentation
in certain case.
Here ( http://blog.ragozin.info/2011/10/cms-heap-fragmentation-follow-up-1.html
 ) you can find some result from my experiments.

Regards,
Alexey

> Hi Andreas,
>
> Am 15.11.2012 10:46, schrieb Andreas M?ller:
>> 2. CMS
>> Cons:
>> - I ran into very bad heap fragmentation after 1 day of full load with
>> only 1 GB of heap and untuned gen sizes (promotion rate was too high).
>> I solved that but do not know at what timescale such problems could
>> reappear in production (risk remains!)
> as you noticed, there are multiple things that you can do in case you
> run into CMS old gen fragmentation issues:
>
> * firstly, monitor the old gen promotion rate of your application by
> using -XX:PrintFLSStatistics=<n> with n=1 or n=2 to collect some data
> * if you notice object allocation requests into old that are
> particularly large in size, try to find out which ones and possibly look
> at whether the application can be redesigned to use smaller objects
> * increase both the young gen and the survivor space size in order to be
> able to garbage collect more of these short and medium lived objects
> during the tenuring process while still in the young gen (i.e. reduce
> the over all promotion rate and object size from young into old)
> * have the CMS GC kick in earlier (i.e. lower initial occupancy ratio
> and set initial occupancy ratio only)
> * or increase the old gen heap - if there is more space available, the
> remaining fragments of free space will automatically become larger.
>
>> - I had to increase heap size from 1GB to 1.5 GB to solve the
>> fragmentation issue
> Maybe applying some more of the above options could even allow you to
> get down a less drastic increase in heap size (50% is much)...
>
> Hope this helps & best regards,
> Andreas
>
> --
> Andreas Loew | Senior Java Architect
> Oracle Advanced Customer Services
> ORACLE Germany