Java Garbage Collection (GC) Tuning

Here is some important parameters that needs to be configured to get good performance on garbage collection. These are what we use in our applications and I will try to explain them one by one:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

JVM_OPTS="-server -d64 -Xloggc:./logs/gc_"$DATE".log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintGCTaskTimeStamps -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -Xms8192m -Xmx8192m -Xss192k -XX:NewSize=4096m -XX:MaxNewSize=4096m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:ParallelGCThreads=16 -XX:ParallelCMSThreads=12 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=70 -XX:-OmitStackTraceInFastThrow"

Line 1: Our application runs on server mod as 64 bit.

Line 2: We set the gc.log file name which will have the application start time. (You may define $DATE as DATE=`date ++%Y%m%d_%H%M` on the previous lines)

Line 3-7: The “print” lines are for what is written on the gc.log file. GC details will be written with time stamps which is number of seconds from the start time of the application. You may also use -XX:+PrintGCDateStamps instead of line 3.

Line 8: Since response time is more important for our real-time charging applications, we use the concurrent collector.

Line 9: For the new generation collection, we enable parallel new generation collector.

Line 10: By default, the classes will stay in the memory forever. Using CMSClassUnloadingEnabled will enable the class unloading from the memory which means that the GC will sweep the perm generation.

Line 11: The total “on heap” size (young+tenured) will be 8GB. Since min and max values are given the same, there will be any grow/shrink operations on the heap. Thus, the virtual boxes on the above image will not exist.

Line 12: Stack size is given as 192K. We use this on T series Sun (oracle) servers and it seems fine.

Line 13-14: New Generation size is given as 4GB. There will not be any grow/shrink operation since the min and max sizes are the same.

Line 15: Permanent size is given as 256MB. This is where the java classes and methods exist.

Line 16: Default is the number of processors on the system. On T Series, there are 256 cores, which means that there will be 256 GC threads by default. This is unnecessary, and also cause trouble of having no idle CPU on the system from time to time. Thus, the number of threads is set to 16.

Line 17: Because of this bug, the number of parallel CMS threads is set to 12.

Line 18: This parameter is a little tricky. There are 2 survivor spaces and this parameter says that the Eden will be (1_survivor_space_size * 8). Assuming that the young generation is 100 MB; 80 MB will be Eden and 10 MB will be each survivor space. Since we had set YG as 4GB, Eden will be ~3.2GB, “from” survivor space will be ~410MB and “to” survivor space will also be ~410MB.

Line 19: This parameter decides when to promote (move from young to tenured) the live object. After that number of minor collections, the object will be promoted.

Line 20: CMS will be started when 70% of the Old (tenured) generation is full.

Line 21: This line will enable correct stack backtrace when there is an exception. This is helpful when debugging the problem.