MaxTenuringThreshold available in ParNewGC?

[Li Li]

1. I don't understand why tenuring thresholds are
calculated to be 1
2. I don't set Xms, I just set Xmx=8g
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/1d7218e8/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