Saturday, December 26, 2015

GC configuration

In this blog, we'll understand the  GC configuration.

-Xmx2560m
-Xms2560m
-XX:CMSInitiatingOccupancyFraction
-Xloggc
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps  
GC settings  and significance

-Xmx2560m  // Max heap memory
-Xms2560m // min heap memory

Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice.

-XX:NewSize=786m   //size of new generation

-XX:MaxNewSize=786m //Max size of new generation
-XX:NewRatio=2 Ratio of old/new generation sizes  // either of two NewSize/NewRatio needed.

-XX:PermSize 

-XX:MaxPermSize=512m // is the range of the size of the permanent generation, which is the non-heap memory

-XX:CMSInitiatingOccupancyFraction=70  // CMS will run after old generation reaches  that pecentage CMS (2560-786)*.7
 -XX:+UseCMSInitiatingOccupancyOnly // optional
CMSInitiatingOccupancyFraction is only used for the 1st collection unless -XX:+UseCMSInitiatingOccupancyOnly is set. 
 default value is approximately 68%. 

-XX
:SurvivorRatio=8 // surviver space will be 1/8th of eden space

-XX:+UseCMSInitiatingOccupancyOnly // if not set the little contiguous free space (i.e. fragmentation) in oldgen a variable which could trigger CMS prior to the set occupancy fraction? 
I.e. is CMS smart enough to take into account the possibility of of clearing out dead objects (thus, reducing fragmentation) before hitting a promotion failure

XX:+CMSScavengeBeforeRemark // This flag allows the JVM to perform a minor GC on the young generation before re-marking, so that the number of objects remaining to be marked in the young gen will be much lower than before the GC. By default, this flag is disabled.

If you don't set the latter switch then, after the first one, the usual heuristics
 (which are based on allocation stats gathered during runtime) are used to determine when CMS starts. 

-Xloggc:<gc_file_location>/logs/gc.log // specify gc log file location
-XX:+PrintTenuringDistribution

XX:+PrintGCApplicationStoppedTime:Total time for which application threads were stopped 
 -XX:+PrintGCApplicationConcurrentTime:Application time
sample output:
Application time: 0.2863875 seconds
Total time for which application threads were stopped: 0.0225087 seconds
Application time: 0.1476791 seconds

Total time for which application threads were stopped: 0.0255697 seconds
-XX:+PrintGCDetails // activate detailed gc logging 
eg.
[GC
    [PSYoungGen: 142816K->10752K(142848K)] 246648K->243136K(375296K),
    0,0935090 secs
]
[Times: user=0,55 sys=0,10, real=0,09 secs]

[Full GC
    [PSYoungGen: 10752K->9707K(142848K)]
    [ParOldGen: 232384K->232244K(485888K)] 243136K->241951K(628736K)
    [PSPermGen: 3162K->3161K(21504K)],
    1,5265450 secs
]
[Times: user=10,96 sys=0,06, real=1,53 secs]

XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps// each line starts with absolute date and time when the logging was written

-XX:+UseConcMarkSweepGC //enable concurrentMarkSweep used for old generation collections
with this most of the gc works happens in the background without stopping application threads.In this applications threads getting stopped kept minimum.

======================================================
-XX:ConcGCThreads=<> //2,3...Number of threads with which the concurrent phase CMS will run.
It is related to ParallelGCThreads

-XX:ParallelGCThreads

The number of garbage collector threads in the young and old generations 
-XX:+UseParallelG // enable throughput collectors

Frequent GC keeps happening at very short interval . This can happen  each times when it is serving request . This is required to cleanup  the short-lived (=new) object  from each request. as they required to to get cleaned up.
 The pause rate is actually very low 0.2/sec and the max pause time of <20ms is good.

Be sure to increase the memory as you increase the number of processors, since allocation can be parallelized.

First we should have the settings using the default settings provided by jvm, then the tuning can be started so that the improvement can be noticed on production. GC viewer:https://github.com/chewiebug/GCViewer

No comments:

Post a Comment