Young generation configuration

Fri Sep 11 20:54:50 UTC 2009


jeff.lloyd at algorithmics.com wrote:
> Hi Tony,
>
> We do have a lot of data that we create/copy within the application.  We
> hold big trees/graphs of data representing large portfolio structures in
> memory per user.  Slicing and dicing the data creates similar strains.
>
> I'll try to increase the YG and play more with MTT to see if I can speed
> things up.  The problem is that we have an interactive web interface so
> the pauses need to be relatively quick or the UI responsiveness suffers.
>
> If I set MTT to 1, then I am guessing I may need to boost my OG size
> because it will fill up faster.  Would it make sense to increase the OG
> size and reduce the initiating occupancy fraction?
>   
Definitely. Someone was paying attention during the talk. :-) But, 
concentrate first on whether the young GC times are good enough.

Tony
> -----Original Message-----
> From: Antonios.Printezis at sun.com [mailto:Antonios.Printezis at sun.com] On
> Behalf Of Tony Printezis
> Sent: Friday, September 11, 2009 11:22 AM
> To: Jeff Lloyd
> Cc: hotspot-gc-use at openjdk.java.net
> Subject: Re: Young generation configuration
>
> Jeff,
>
> Hi. I had a very brief look at your logs. Yes, your app does seem to 
> need to copy quite a lot (I don't think I've ever seen 1-2GB of data 
> being copied in age 1!!!). From what I've seen from the space sizes, 
> you're doing the right thing (i.e., you're consistent with what we 
> talked about during the talk): you have quite large young gen and a 
> reasonably sized old gen. But the sheer amount of surviving objects is 
> what's getting you. How much larger can you make your young gen? I think
>
> in this case, the larger, the better.  Maybe, you can also try 
> MaxTenuringThreshold=1. This goes against our general advice, but this 
> might decrease the amount of objects being copied during young GCs, at 
> the expense of more frequent CMS cycles...
>
> Tony
>
> jeff.lloyd at algorithmics.com wrote:
>   
>> Hi,
>>
>>  
>>
>> I'm new to this list and I have a few questions about tuning my young 
>> generation gc.
>>
>>  
>>
>> I have chosen to use the CMS garbage collector because my application 
>> is a relatively large reporting server that has a web front end and 
>> therefore needs to have minimal pauses. 
>>
>>  
>>
>> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB
>>     
> ram.
>   
>>  
>>
>> The machine is dedicated to this JVM.
>>
>>  
>>
>> My steady-state was calculated as follows:
>>
>> -          A typical number of users logged in and viewed several
>>     
> reports
>   
>> -          Stopped user actions and performed a manual full GC
>>
>> -          Look at the amount of heap used and take that number as the
>>     
>
>   
>> steady-state memory requirement
>>
>>  
>>
>> In this case my heap usage was ~10GB.  In order to handle variance or 
>> spikes I sized my old generation at 15-20GB.
>>
>>  
>>
>> I sized my young generation at 32-42GB and used survivor ratios of 1, 
>> 2, 3 and 6.
>>
>>  
>>
>> My goal is to maximize throughput and minimize pauses.  I'm willing to
>>     
>
>   
>> sacrifice ram to increase speed.
>>
>>  
>>
>> I have attached several of my many gc logs.  The file gc_48G.txt is 
>> just using CMS without any other tuning, and the results are much 
>> worse than what I have been able to accomplish with other settings.  
>> The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and 
>> gc_57G_15Gold_42Gyoung_1sr.txt.
>>
>>  
>>
>> The problem is that some of the pauses are just too long.
>>
>>  
>>
>> Is there a way to reduce the pause time any more than I have it now?
>>
>> Am I heading in the right direction?  I ask because the default 
>> settings are so different than what I have been heading towards.
>>
>>  
>>
>> The best reference I have found on what good gc logs look like come 
>> from brief examples presented at JavaOne this year by Tony Printezis 
>> and Charlie Hunt.  But I don't seem to be able to get logs that 
>> resemble their tenuring patterns.
>>
>>  
>>
>> I think I have a lot of medium-lived objects instead of nice 
>> short-lived ones.
>>
>>  
>>
>> Are there any good practices for apps with objects like this?
>>
>>  
>>
>> Thanks,
>>
>> Jeff
>>
>>  
>>
>>  
>>
>>     
> ------------------------------------------------------------------------
>   
>> This email and any files transmitted with it are confidential and 
>> proprietary to Algorithmics Incorporated and its affiliates 
>> ("Algorithmics"). If received in error, use is prohibited. Please 
>> destroy, and notify sender. Sender does not waive confidentiality or 
>> privilege. Internet communications cannot be guaranteed to be timely, 
>> secure, error or virus-free. Algorithmics does not accept liability 
>> for any errors or omissions. Any commitment intended to bind 
>> Algorithmics must be reduced to writing and signed by an authorized 
>> signatory.
>>
>>     
> ------------------------------------------------------------------------
>   
> ------------------------------------------------------------------------
>   
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>     
>
>   

-- 
---------------------------------------------------------------------
| Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
|                                  | MS UBUR02-311                  |
| e-mail: tony.printezis at sun.com   | 35 Network Drive               |
| office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
---------------------------------------------------------------------
e-mail client: Thunderbird (Linux)


_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use