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

[Seth Theriault]

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 
is.

You may wish to subsititute:

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

with:

-XX:+UseParallelGC -XX:+UseParallelOldGC

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

-XX:ParallelGCThreads=<number>

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:

http://www.tagtraum.com/gcviewer.html

That site also maintains a pretty good explanation of the GC 
flags:

http://www.tagtraum.com/gcviewer-vmflags.html

Seth