[Building Sakai] Java 6 garbage collection

[Aaron Zeckoski]

If you really want to use the concurrent collector you should probably
consider enabling the survivor spaces as well. Something like this
will do that.
-XX:SurvivorRatio=6 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=12

Doing this will keep a lot of objects form ever reaching your eden space.

I would also recommend against a heap as huge as the one you have
indicated. Huge spaces mean large pauses for collections.

-AZ


On Wed, Sep 23, 2009 at 7:04 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> 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.
>
>
> _______________________________________________
> 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"
>



-- 
Aaron Zeckoski (azeckoski (at) vt.edu)
Senior Research Engineer - CARET - University of Cambridge
https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile