This post highlights three performance tuning techniques for Red Hat Enterprise Linux (6.2) and OpenJDK (1.6): TCP send / receive windows, large page memory, and i-CMS.
These techniques are particularly applicable to data grids or to any distributed system that stores a lot of data.
I just finished a technical white paper on JBoss Data Grid (JDG) performance factors, and these techniques were necessary for JDG to perform at its best.
Networking
Set the maximum size of the TCP send / receive windows of the accordingly.
Example: 640K Send Window / 25MB Receive Window
echo 655360 > /proc/sys/net/core/wmem_max echo 26214400 > /proc/sys/net/core/rmem_max
Memory
Configure large page memory. More information about large page memory can be found here.
Example: A server with 16GB of memory with 12.5GB of it reserved for large page memory.
echo 17179869184 > /proc/sys/kernel/shmmax echo 6400 > /proc/sys/vm/nr_hugepages echo 500 > /proc/sys/vm/hugetlb_shm_group
Update the resource limits.
/etc/security/limits.conf
jboss soft memlock unlimited jboss hard memlock unlimited
Set the JVM options.
Note: The heap size (12GB) is less than the amount of memory reserved for large page memory (12.5GB) as the heap is not the only memory used by the JVM.
-Xms12G -Xmx12G -XX:+UseLargePages
Garbage Collection
Use the Concurrent Mark Sweep (CMS) garbage collector in Incremental mode (i-CMS).
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
January 9, 2013 at 12:27 am
nice performance tuning tips. Are these applicable to other JDK like jrockit?
January 9, 2013 at 12:27 pm
While I am running RHEL and OpenJDK, these techniques (large page memory / i-CMS) should be applicable to any other JVM including JRockit.
January 10, 2013 at 8:18 am
Would this be applicable to running JBoss as well?
January 10, 2013 at 10:01 am
It would. If your application servers are clustered, it is worth updating the TPC send / receive windows. If your application requires a lot of memory, it is worth configuring and enabling large page memory. However, your choice in garbage collector will depend on your application requirements. I chose the concurrent collector because I wanted to minimize GC pause time. If I wanted to maximize peak performance, I might have selected the parallel collector.
February 8, 2013 at 1:00 pm
Reblogged this on Mani's useful blogs and commented:
Short and sweet blog on Performance tuning!
February 13, 2013 at 3:33 am
Great read, this can be very useful to any Java J2EE developer