[Building Sakai] Java 6 garbage collection

[Charles Hedrick]

Under Java 6 I'm getting a good size survivor space by default. I'm  
trying to avoid specifying any more than I have to, because new  
versions of Java tend to change strategies and adjust the defaults. I  
looked at the way eden and survivor are working, and found that the  
default setup looked good. Under Java 5 we did something like what you  
suggest. So far the only things I think we need to specify under 6 are  
the initiatingOccupanyFraction, because it defaults as too large, and  
the size of perm, because the default is way too low. I think I could  
let Java compute the size of new. The default in 6 is much larger than  
it was in 5.

At times I've seen over 5 GB in old after a GC. Since usage is still  
growing I'm uncomfortable with less than 8 GB as the starting point  
for a GC of old. To avoid problems with fragmentation that means 10 GB  
for the space. Add in 3 GB for new and you've got 13 GB. We could of  
course run two JVMs on the system, but that worries me for other  
reasons.


On Sep 23, 2009, at 5:31:27 PM, Aaron Zeckoski wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090923/317cdce4/attachment.bin