[Building Sakai] [Deploying Sakai] JVM GC tuning for Java 1.6

[Earle Nietzel]

Using the Parallel GC on a large heap is not a good idea since it will 
cause application pausing when it gets busy.

On larger heaps use the low pause GC as that will minimize pausing and if 
configured correctly can eliminate pausing.

Here is our _current_ JVM options which has been working well so far:

JAVA_OPTS="-server -d64 -Djava.awt.headless=true 
-Djava.library.path=/usr/lib -Dsun.net.inetaddr.ttl=60 
-Dsun.rmi.dgc.client.gcInterval=3600000 
-Dsun.rmi.dgc.server.gcInterval=3600000 -Xms6g -Xmx6g -XX:NewSize=768m 
-XX:MaxNewSize=768m -XX:PermSize=512m -XX:MaxPermSize=512m 
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing 
-XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:SurvivorRatio=6 
-XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintHeapAtGC 
-Xloggc:/var/log/tomcat5/tomcat.vgc"

Reason why people make references like "GC tuning can be black art" is 
that every JVM is different even if were all running the same application. 
You have to consider that users at one Institution are not the same as 
another and the JVM needs to be tuned according to that specific instance 
of that application given its expected usage. 

Maybe the "black art" part of this is figuring out how your JVM is running 
so that you can determine if tuning is required. There are many good 
references on how to tune your JVM and I would suggest to any 
administrator managing a JVM to read them. The log that gets produced 
above /var/log/tomcat5/tomcat.vgc (because I don't like my performance 
data mixed in catalina.out) is the key to understanding how your JVM is 
running. There are many JVM log analyzer's that exist to aid you as well.

Though in the end it just takes time and effort,
Earle



From:   Robert Cohen <robert.cohen at anu.edu.au>
To:     Stephen Marquard <stephen.marquard at uct.ac.za>, 
<production at collab.sakaiproject.org>, <sakai-dev at collab.sakaiproject.org>
Date:   08/20/2010 02:07 AM
Subject:        Re: [Building Sakai] [Deploying Sakai] JVM GC tuning for 
Java 1.6
Sent by:        sakai-dev-bounces at collab.sakaiproject.org



Yeah, I get the impression that GC tuning is definitely a black art.

We're using 

-server -Xms1500m -Xmx1500m  -XX:MaxPermSize=512m -XX:PermSize=512m
-XX:+UseParallelGC -XX:GCTimeRatio=49 -verbose:gc -XX:+PrintGCTimeStamps
-XX:+PrintGCDetails

and while I don't suggest its a definitive benchmark, using those settings
on our test server I get a tomcat startup time of 86 sec.

Whereas with something similar to your settings I see a startup time of
around 96 secs.

You can probably shave a couple of seconds off your startup time by adding
-XX:PermSize=512m

And UseParallelGC instead of ConcMarkSweep might be worth a try.


On 19/8/10 7:30 PM, "Stephen Marquard" <stephen.marquard at uct.ac.za> wrote:

> Hi all,
> 
> I recently asked about GC settings for java 1.6, as our GC behaviour got
> significantly worse when we moved from 1.5 to 1.6.
> 
> We've now updated our GC settings to:
> 
> -server -d64 -Xms5000m -Xmx5000m -XX:MaxPermSize=512m 
-XX:+UseConcMarkSweepGC
> -XX:+ExplicitGCInvokesConcurrent -XX:+CMSIncrementalMode -verbose:gc
> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps
> 
> with good results. We were previously using:
> 
> -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 -XX:+DisableExplicitGC
> 
> Regards
> Stephen
> 
> 
> 
> 
> 
> ###
> UNIVERSITY OF CAPE TOWN
> 
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer 
published
> on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ 
or
> obtainable from +27 21 650 4500. This e-mail is intended only for the
> person(s) to whom it is addressed. If the e-mail has reached you in 
error,
> please notify the author. If you are not the intended recipient of the 
e-mail
> you may not use, disclose, copy, redirect or print the content. If this 
e-mail
> is not related to the business of UCT it is sent by the sender in the 
sender's
> individual capacity.
> 
> ###
> 
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
> 
> TO UNSUBSCRIBE: send email to 
production-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"

=======================================
Robert Cohen
Systems & Desktop Services
Division of Information
R.G Menzies Building
Building 2
The Australian National University
Canberra ACT 0200 Australia

T: +61 2 6125 8389
F: +61 2 6125 7699
http://www.anu.edu.au

CRICOS Provider #00120C
=======================================


_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to 
sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of 
"unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100820/d9d82855/attachment.html