JVM Heap & GC Tuning…

So, obviously, I haven’t posted anything here in a whileSmile.  Life has been busy.  Starting several months ago, I left my job of four years and began independent consulting.  Among other things, this means that the variety of topics discussed on thinkmiddleware.com should be more varied.  I’m also going to make it a point to post more often.  This probably means that the posts won’t be as lengthy or as organized as they have been in the past.

In this post, I’m going to summarize the typical memory and GC(Garbage Collection) settings that I’ve used for a server-side JVM.  I’m going to use Java 1.6 JVMs for this example.  The JVM Spec does not define specifics around heap memory architecture and garbage collection.  The author’s of the spec wanted to leave the details to the creativity of the virtual machine implementers.

As a result of this, efficiently tuning JVM memory and GC is unique to each JVM vendor’s implementation.  Below I provide the typical settings that I use as a starting place for a Sun/Oracle & IBM JVM.

Sun/Oracle HotSpot JVM

I use the following typically as a starting point when the the -Xmx parameter is over 1gb:

-server -Xmx1024m -Xms1024m -XX:MaxPermSize=256m -XX:PermSize=56m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:-UseConcMarkSweepGC -XX:-UseParallelGC -XX:-DisableExplicitGC

To enable garbage collection, include the following:

-verbose:gc -X:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

Information about these options and many others can be found here.

VisualGC can be used to monitor Java Heap usage, JIT Compiler activity, classloader activity, and GC activity.  To properly use this tool does require some knowledge of how the IBM Java heap is organized, which I haven’t explained here.


I use the following typically as a starting point when the the -Xmx parameter is over 1gb:

-Xms1024m -Xmx1024m -Xmn256mb -Xgc:splitheap  -Xdisableexplicitgc

To enable GC logging:

-verbose:gc -Xverbosegclog:gc.log

Information about how the IBM Java Heap and GC algorithms work can be found in the reference section.

Garbage Collection tuning is a journey, not a destination-like so many other things performance tuning.  You might accomplish 80% of the improvements in the first couple of testing iterations.  The last 20% may be elusive.  Once you have gotten performance under control, as traffic patterns and memory usage changes, the GC requirements will change as well.