[Building Sakai] Java 6 garbage collection
Charles Hedrick
hedrick at rutgers.edu
Wed Sep 23 10:04:07 PDT 2009
We're using Java 6 with Sakai 2.6. As the load has come on during Sept
we've started seeing pauses due to garbage collection. Some are
unavoidable. However some are a result of changes in defaults between
Java 5 and Java 6. Most of the changes are good, but one is not: When
using CMS (the concurrent low-pause collector), it used to be that a
GC of old was by default started when old was 68% full. That's a bit
too conservative, so many people set -
XX:CMSInitiatingOccupancyFraction to a higher value. In Java 6, the
default is more complex, but in many cases it works out to be
something over 90%. I've seen claims that it's 92%. That sounds about
right. This is far too high a value. It can result in full GC's and
also fragmentation of memory leading to long minor GCs. If you carry
over your old Java 5 value for CMSInitiatingOccupancyFraction you
should be fine, but if you let it default, you are likely to be in for
trouble. I'm currently using 80%. Here are our current values. This is
with 1.6.0u16.
JAVA_OPTS=" -d64 -Dsun.lang.ClassLoader.allowArraySyntax=true -
Xmx13000m -Xms13000m -Xmn3g -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -
XX:CMSInitiatingOccupancyFraction=80 -XX:MaxPermSize=512m -
XX:PermSize=64m "
I actually recommend setting PermSize to a value appropriate to your
installation, by using jstat to see what perm space usage actually is.
That will save you from a few long GCs early in your JVM's lifetime.
With these tunings, pauses are normally OK. However certain behavior
can get a JVM into a state where minor GC's are 20 - 30 sec. In my
opinion the new GC ("G1") is the only final solution to GC-related
pauses in large JVMs. We're trying that on one system, but I'm not
sure it's ready for production use.
More information about the sakai-dev
mailing list