MaxTenuringThreshold available in ParNewGC?

Wed Jan 11 09:24:02 UTC 2012

the log is too large to post here
I just post some lines here. I grep the lines that gc time is larger than
100ms.
the question is: at the beginning, young generation is about 50M. but after
running a while, the memory is growing to 1.8GB. 1.75GB is Eden and 0.2G is
s0 and s1.
e.g. [GC [ParNew: 1843200K->204800K(1843200K), 0.2584570 secs]
it is clear that the eden is 1843200K(1.75G), s0 is 0.2G.
before young gc, eden are all used. after gc, s1 is all used(other live
object are moved to old generation)

2012-01-10T18:26:45.992+0800: [GC [ParNew: 58732K->6528K(59072K), 0.1234300
secs] 1391982K->1375194K(1707564K), 0.1234900 secs] [Times: user=1.44
sys=0.02, real=0.12 secs]
2012-01-10T18:26:47.185+0800: [GC [ParNew: 59072K->6528K(59072K), 0.1335480
secs] 1507767K->1490151K(2340184K), 0.1336020 secs] [Times: user=1.60
sys=0.01, real=0.13 secs]
2012-01-10T18:26:56.605+0800: [GC [ParNew: 59072K->6528K(59072K), 0.0992650
secs] 1523647K->1509678K(2522312K), 0.0993220 secs] [Times: user=1.22
sys=0.01, real=0.10 secs]
2012-01-10T18:26:57.395+0800: [GC [ParNew: 52998K->6528K(59072K), 0.1948650
secs] 1556149K->1544918K(2522312K), 0.1949120 secs] [Times: user=2.46
sys=0.01, real=0.19 secs]
2012-01-10T18:27:05.072+0800: [GC [ParNew: 38463K->6528K(59072K), 0.1571700
secs] 2449032K->2447103K(2864820K), 0.1572150 secs] [Times: user=1.98
sys=0.02, real=0.16 secs]
2012-01-10T18:27:06.220+0800: [GC [ParNew: 59072K->6528K(59072K), 0.1641610
secs] 2499647K->2483866K(2864820K), 0.1642060 secs] [Times: user=2.07
sys=0.01, real=0.17 secs]
2012-01-10T22:24:08.939+0800: [GC [ParNew: 1826901K->204800K(1843200K),
0.1418510 secs] 3923985K->2352398K(7987200K), 0.1420700 secs] [Times:
user=1.59 sys=0.05, real=0.14 secs]
2012-01-10T22:24:09.343+0800: [GC [ParNew: 1843200K->175652K(1843200K),
0.1994980 secs] 3990798K->2536312K(7987200K), 0.1996880 secs] [Times:
user=1.98 sys=0.02, real=0.20 secs]
2012-01-10T22:24:10.049+0800: [GC [ParNew: 1814052K->151709K(1843200K),
0.1409050 secs] 4174712K->2618929K(7987200K), 0.1410940 secs] [Times:
user=1.51 sys=0.00, real=0.14 secs]
2012-01-10T22:24:11.015+0800: [GC [ParNew: 1843200K->204800K(1843200K),
0.2584570 secs] 4311783K->2831783K(7987200K), 0.2586440 secs] [Times:
user=2.83 sys=0.00, real=0.26 secs]
2012-01-10T22:24:11.543+0800: [GC [ParNew: 1843200K->188261K(1843200K),
0.2356920 secs] 4470183K->3028255K(7987200K), 0.2358800 secs] [Times:
user=2.41 sys=0.01, real=0.24 secs]

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

>
> On 2012-01-11, at 9:06 AM, Li Li wrote:
>
> 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
>
>
> Right, ratios are adaptive and if you're using CMS, will require a full GC
> to occur before they will adapt. Size will start off small and then get
> bigger as needed.
>
> 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.
>
>
> Well, if memory use stabilizes than you don't have a leak. But I'd need to
> see a GC log to give you better advice. All I can say is that the more
> switches you touch the more you've got to understand about how things work
> in order to make effective changes. I generally start with minimal switch
> settings and then adjust as needed. Starting with a ratio is better than
> starting with a fixed value. If the ratio isn't working for you then moved
> to a fixed size. But use the data in the gc log to tell you how to proceed.
>
> Also, if your application is swapping during GC you will increase the
> duration of the collection. You need to monitor system level activity as
> part of the investigation.
>
> Regards,
> Kirk
>
>
> 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
>>>
>>>
>>>
>>
>>
> _______________________________________________
> 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/325a0052/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