MaxTenuringThreshold available in ParNewGC?

Wed Jan 11 08:06:48 UTC 2012

I understand the first one.
as for Xmx, when it reach the maxium 8GB, the young generation is in deed
1.8G and Eden:s0:s1=8:1:1. That's correct.
but when I restart it for a few minutes. old is 4GB while young is 200-300MB
I don't think there is memory leak because it has running for more than a
month without OOV.
My application is using lucene+solr to provide search service which need
large memory.

On Wed, Jan 11, 2012 at 3:55 PM, Kirk Pepperdine
<kirk.pepperdine at gmail.com>wrote:

>
> On 2012-01-11, at 8:47 AM, Li Li wrote:
>
> 1. I don't understand why tenuring thresholds are
> calculated to be 1
>
>
> because the number of expected survivors exceeds the size of the survivor
> space
>
> 2. I don't set Xms, I just set Xmx=8g
>
>
> with a new ratio of 3.. you should have 2 gigs of young gen meaning a .2
> gigs for each survivor space and 1.6 for young gen. Do you have a GC log
> you can use to confirm these values? If not try visualvm and this plugin
> should give you a clear view (www.java.net/projects/memorypoolview).
>
>
> 3. as for memory leak, I will try to find it.
>
> On Wed, Jan 11, 2012 at 3:18 PM, Kirk Pepperdine <kirk at kodewerk.com>wrote:
>
>> Hi Li LI,
>>
>> I fear that you are off in the wrong direction. Resetting tenuring
>> thresholds in this case will never work because they are being calculated
>> to be 1. You're suggesting numbers greater than 1 and so 1 will always be
>> used which explains why you're not seeing a difference between runs. Having
>> a calculated tenuring threshold set to 1 implies that the memory pool is
>> too small. If the a memory pool is too small the only thing you can do to
>> fix that is to make it bigger. In this case, your young generational space
>> (as I've indicated in previous postings) is too small. Also, the cost of a
>> young generational collection is dependent mostly upon the number of
>> surviving objects, not dead ones. Pooling temporary objects will only make
>> the problem worse. If I recall your flag settings, you've set netsize to a
>> fixed value. That setting will override the the new ratio setting. You also
>> set Xmx==Xms and that also override adaptive sizing. Also you are using CMS
>> which is inherently not size adaptable.
>>
>> Last point, and this is the biggest one. The numbers you're publishing
>> right now suggest that you have a memory leak. There is no way you're going
>> to stabilize the memory /gc behaviour with a memory leak. Things will get
>> progressively worse as you consume more and more heap. This is a blocking
>> issue to all tuning efforts. It is the first thing that must be dealt with.
>>
>> To find the leak;
>> Identify the leaking object useing VisualVM's memory profiler with
>> generational counts and collect allocation stack traces turned on. Sort the
>> profile by generational counts. When you've identified the leaking object,
>> the domain class with the highest and always increasing generational count.
>> take an allocation stack trace snapshot and a heap dump. The heap dump
>> should be loaded into a heap walker. Use the knowledge gained from
>> generational counts to inspect the linkages for the leaking object and then
>> use that information in the allocation stack traces to identify casual
>> execution paths for creation. After that, it's into application code to
>> determine the fix.
>>
>> Kind regards,
>> Kirk Pepperdine
>>
>> On 2012-01-11, at 5:45 AM, Li Li wrote:
>>
>>   if the young generation is too small that it can't afford space for
>> survivors and it have to throw them to old generation. and jvm found this,
>> it will turn down TenuringThreshold ?
>>    I set TenuringThreshold to 10. and found that the full gc is less
>> frequent and every full gc collect less garbage. it seems the parameter
>> have the effect. But I found the load average is up and young gc time is
>> much more than before. And the response time is also increased.
>>    I guess that there are more objects in young generation. so it have to
>> do more young gc. although they are garbage, it's not a good idea to
>> collect them too early. because ParNewGC will stop the world, the response
>> time is increasing.
>>    So I adjust TenuringThreshold to 3 and there are no remarkable
>> difference.
>>    maybe I should use object pool for my application because it use many
>> large temporary objects.
>>    Another question, when my application runs for about 1-2 days. I found
>> the response time increases. I guess it's the problem of large young
>> generation.
>>     in the beginning, the total memory usage is about 4-5GB and young
>> generation is 100-200MB, the rest is old generation.
>>     After running for days, the total memory usage is 8GB and young
>> generation is about 2GB(I set new Ration 1:3)
>>     I am curious about the heap size adjusting. I found –XX:MinHeapFreeRation
>> and –XX:MaxHeapFreeRation
>>    the default value is 40 and 70. the memory manage white paper says if
>> the total heap free space is less than 40%, it will increase heap. if the
>> free space is larger than 70%, it will decrease heap size.
>>    But why I see the young generation is 200mb while old is 4gb. does the
>> adjustment of young related to old generation?
>>    I read in
>> http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/ young
>> generation should be less than 512MB, is it correct?
>>
>>
>>
>> On Wed, Jan 11, 2012 at 1:23 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:
>>
>>> I recommend Charlie's excellent book as well.
>>>
>>> To answer yr question, yes, CMS + Parew does use MaxTenuringThreshold
>>> (henceforth MTT),
>>> but in order to allow objects to age you also need sufficiently large
>>> survivor spaces to hold
>>> them for however long you wish, otherwise the adaptive tenuring policy
>>> will adjust the
>>> "current" tenuring threshold so as to prevent overflow. That may be what
>>> you saw.
>>> Check out the info printed by +PrintTenuringThreshold.
>>>
>>> -- ramki
>>>
>>> On Tue, Jan 10, 2012 at 1:31 AM, Li Li <fancyerii at gmail.com> wrote:
>>>
>>>> hi all
>>>>    I have an application that generating many large objects and then
>>>> discard them. I found that full gc can free memory from 70% to 40%.
>>>>    I want to let this objects in young generation longer. I found
>>>> -XX:MaxTenuringThreshold and -XX:PretenureSizeThreshold.
>>>>    But I found a blog that says MaxTenuringThreshold is not used in
>>>> ParNewGC.
>>>> And I use ParNewGC+CMS. I tried to set MaxTenuringThreshold=10, but it
>>>> seems no difference.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120111/243309d6/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use