Young generation configuration

Sat Sep 12 00:00:02 UTC 2009

Could be, but that would lead to a lot of concurrent overhead, reducing
his throughput.  Such a balancing act. :)

Paul

Tony Printezis wrote:
>
>
> Paul Hohensee wrote:
>> You can try out compressed pointers in 6u14.  It just won't be quite as
>> fast as the version that's going into 6u18.  6u14 with compressed 
>> pointers
>> will still be quite a bit faster than without.
>>
>> One of the gc guys may correct me, but UseAdaptiveGCBoundary allows
>> the vm to ergonomically move the boundary between old and young 
>> generations,
>> effectively resizing them.  I don't know if it's bit-rotted, and I 
>> seem to remember
>> that there wasn't much benefit.  But maybe we just didn't have a good 
>> use case.
>>   
> Also, it's ParallelGC-only, IIRC.
>> What I meant by the last paragraph was that with the tenuring 
>> threshold set at
>> 15 (which is what the log says), and with only 7 young gcs in the 
>> log, we can't
>> see at what age (or if) between 8 and 15 the survivor size goes down 
>> to something
>> reasonable.  If it doesn't, it might be worth it to us to revisit 
>> increasing the age
>> limit for 64-bit.
>>   
> Paul, the problem in Jeff's case is that even at age 1 he copies 1GB 
> or so. So, maybe, setting a small MTT and having more CMS cycles might 
> be the right option for him.
>
> Tony
>> jeff.lloyd at algorithmics.com wrote:
>>  
>>> Thanks for your response Paul.
>>>
>>> I'll take another look at the parallel collector. 
>>> That's a good point about the -XX:+UseCompressedOops.  We started off
>>> with heaps bigger than 32G so I had left that option out.  I'll put it
>>> back in and definitely try out 6u18 when it's available.
>>>
>>> What about the option -XX:+UseAdaptiveGCBoundary?  I don't see it
>>> referenced very often.  Would it be helpful in a case like mine?
>>>
>>> I'm not sure I understand your last paragraph.  What is the period of
>>> time that you would be interested in seeing?
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] Sent: 
>>> Friday, September 11, 2009 1:23 PM
>>> To: Tony Printezis
>>> Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net
>>> Subject: Re: Young generation configuration
>>>
>>> Another alternative mentioned in Tony and Charlie's J1 slides is the 
>>> parallel
>>> collector.  If, as Tony says, you can make the young gen large 
>>> enough to
>>>
>>> avoid
>>> promotion, and you really do have a steady state old gen, then which 
>>> old
>>> gen
>>> collector you use wouldn't matter much to pause times, given that young
>>> gen pause times seem to be your immediate problem.
>>>
>>> It may be that you just need more hardware threads to collect such a 
>>> big
>>>
>>> young
>>> gen too.  You might vary the number of gc threads to see how that
>>> affects
>>> collection times.  If there's significant differences, then you need
>>> more
>>> hardware threads, i.e., a bigger machine.
>>>
>>> You might also try using compressed pointers via 
>>> -XX:+UseCompressedOops.
>>> That should cut down the total survivor size significantly, perhaps
>>> enough
>>> to that your current hardware threads can collect significantly faster.
>>>
>>> Heap size
>>> will be limited to < 32gb, but you're app will probably fit.  A more 
>>> efficient
>>> version of compressed pointers will be available in 6u18, btw.
>>>
>>> I notice that none of your logs shows more than age 7 stats even though
>>> the
>>> tenuring threshold is 15.  It'd be nice to see if anything dies before
>>> then.
>>>
>>> Paul
>>>
>>> Tony Printezis wrote:
>>>      
>>>> 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
>>>>>                   
>>>>             
>>>  
>>> -------------------------------------------------------------------------- 
>>>
>>> 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
>>   
>
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use