Young generation configuration
jeff.lloyd at algorithmics.com
jeff.lloyd at algorithmics.com
Mon Sep 14 14:12:04 PDT 2009
Is there somewhere I can download a balancing pole? :-)
Thanks, you guys have been great help.
Jeff
-----Original Message-----
From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM]
Sent: Friday, September 11, 2009 8:00 PM
To: Tony Printezis
Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net
Subject: Re: Young generation configuration
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
>>
>
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
More information about the hotspot-gc-use
mailing list