[WG: Production / Deploying Sakai] Revisiting app server GC settings - advice sought

Seth Theriault slt at columbia.edu
Mon Mar 16 06:42:55 PDT 2009

Stephen Marquard wrote:

> Our current GC settings are:
> -server -d64 -Xms5000m -Xmx5000m -Xmn1g -XX:MaxPermSize=512m 
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:GCTimeRatio=19
> -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 
> -XX:MaxTenuringThreshold=31 -verbose:gc -XX:+PrintGCDetails 
> -XX:+PrintGCTimeStamps -Xloggc:/usr/local/sakai/logs/gc.log

By default, assuming you are using "server class" machine, the 
JVM would be using "parallel" garbage collection instead of the 
concurrent that you are using. Is there a specific reason why you 
are choosing concurrent? It's OK to say I don't know, because 
that was my response also at some point in the past -- and still 

You may wish to subsititute:

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC


-XX:+UseParallelGC -XX:+UseParallelOldGC

When you set the "parallel" GC, you can also specify how many GC 
threads you want running:


By default this is N on an N-CPU box. You probably want to set it 
to less than that; I read that somewhere along the line.

Some people have had success with setting as few JVM paramters as 
possible and letting the JVM itself work things out. That might 
work too.

> Some extracts from our gc.log files are below. The first column 
> is seconds since app server start. The lines that I've left out 
> are all the short "ParNew" GCs. The problematic behaviour is a 
> whole series of Full GCs in a row, e.g. starting at 70622.

Consider putting your GC logs through this analyzer:


That site also maintains a pretty good explanation of the GC 



More information about the production mailing list