I understand the first one.<div>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.</div><div>but when I restart it for a few minutes. old is 4GB while young is 200-300MB</div>
<div>I don't think there is memory leak because it has running for more than a month without OOV.</div><div>My application is using lucene+solr to provide search service which need large memory. <br><br><div class="gmail_quote">
On Wed, Jan 11, 2012 at 3:55 PM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk.pepperdine@gmail.com">kirk.pepperdine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On 2012-01-11, at 8:47 AM, Li Li wrote:</div><br><blockquote type="cite">1. I don't understand why tenuring thresholds are <div>calculated to be 1</div></blockquote>
<div><br></div></div>because the number of expected survivors exceeds the size of the survivor space</div><div><div class="im"><br><blockquote type="cite"><div>2. I don't set Xms, I just set Xmx=8g</div></blockquote><div>
<br></div></div>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 (<a href="http://www.java.net/projects/memorypoolview" target="_blank">www.java.net/projects/memorypoolview</a>).</div>
<div><div class="h5"><div><br></div><div><br><blockquote type="cite"><div>3. as for memory leak, I will try to find it.<br><br><div class="gmail_quote">On Wed, Jan 11, 2012 at 3:18 PM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Li LI,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>To find the leak;</div><div>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.</div>
<div><br></div><div>Kind regards,</div><span><font color="#888888"><div>Kirk Pepperdine</div></font></span><div><div><div><br><div><div>On 2012-01-11, at 5:45 AM, Li Li wrote:</div><br><blockquote type="cite">
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 <span>TenuringThreshold ? </span><div>
<font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> I set </span></font><span>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.</span></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> 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.</span></font></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> So I adjust </span></font><span>TenuringThreshold to 3 and there are no remarkable difference. </span></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> maybe I should use object pool for my application because it use many large temporary objects.</span></font></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> 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.</span></font></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> in the beginning, the total memory usage is about 4-5GB and young generation is 100-200MB, the rest is old generation.</span></font></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> After running for days, the total memory usage is 8GB and young generation is about 2GB(I set new Ration 1:3)</span></font></div>
<div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"> I am curious about the heap size adjusting. I found </span></font><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:22px">–XX:MinHeapFreeRation and </span>–XX:MaxHeapFreeRation</div>
<div> 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.</div><div>
But why I see the young generation is 200mb while old is 4gb. does the adjustment of young related to old generation?</div><div> I read in <a href="http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/" target="_blank">http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/</a> young generation should be less than 512MB, is it correct?</div>
<div><br></div><div><font color="#222222" face="arial, sans-serif"><span style="font-size:22px"><br></span></font><br><div class="gmail_quote">On Wed, Jan 11, 2012 at 1:23 AM, Srinivas Ramakrishna <span dir="ltr"><<a href="mailto:ysr1729@gmail.com" target="_blank">ysr1729@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I recommend Charlie's excellent book as well.<br><br>To answer yr question, yes, CMS + Parew does use MaxTenuringThreshold (henceforth MTT),<br>
but in order to allow objects to age you also need sufficiently large survivor spaces to hold<br>
them for however long you wish, otherwise the adaptive tenuring policy will adjust the<br>"current" tenuring threshold so as to prevent overflow. That may be what you saw.<br>Check out the info printed by +PrintTenuringThreshold.<br>
<br>-- ramki<br><br><div class="gmail_quote"><div><div>On Tue, Jan 10, 2012 at 1:31 AM, Li Li <span dir="ltr"><<a href="mailto:fancyerii@gmail.com" target="_blank">fancyerii@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
hi all<div> 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%. </div><div> I want to let this objects in young generation longer. I found -XX:MaxTenuringThreshold and -XX:PretenureSizeThreshold.</div>
<div> But I found a blog that says MaxTenuringThreshold is not used in ParNewGC.</div><div>And I use ParNewGC+CMS. I tried to set MaxTenuringThreshold=10, but it seems no difference.</div>
<br></div></div><div>_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
<br></div></blockquote></div><br>
</blockquote></div><br></div>
_______________________________________________<br>hotspot-gc-use mailing list<br><a href="mailto:hotspot-gc-use@openjdk.java.net" target="_blank">hotspot-gc-use@openjdk.java.net</a><br><a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>