问题描述
这些是我在WebLogic 11g中的Sun Hotspot 1.6 JVM堆设置：
-Xms10g -Xmx10g -XX：MaxPermSize = 256m -XX：+ UseParNewGC -XX：ParallelGCThreads = 2 -XX：+ UseConcMarkSweepGC -XX：+ CMSParallelRemarkEnabled -XX：ConcGCThreads = 2
我在24小时的JVM堆空闲％图中看到的基本上无堆％以较慢的速率下降，直到我们达到约9％（需要大约24小时）。然后系统运行一个完整的gc，并回到97％。
是否有一些设置需要添加/修改，这会告诉JVM尽快完成全面的GC，而不是比我们获得10％以下的堆空闲时更快？例如一些比率设置？
它没有造成它等到我们获得9％免费的问题，但它使监控/警报更加困难。理想情况下，我们希望始终保持高于30％的免费比例，这样，如果我们下降到这些单个数字，我们知道存在某种问题，例如内存泄漏。
使用其他计算器文章的组合找到答案。
-XX：+ UseCMSInitiatingOccupancyOnly -XX：CMSInitiatingOccupancyFraction = N
其中N大致占用的百分比将触发完整的GC。默认值是〜92，这就是为什么我看到完整的GC在9％免费。切换到65为我的用例工作。完整的GC发生约35％的免费现在。
These are my Sun Hotspot 1.6 JVM heap settings in WebLogic 11g:
-Xms10g -Xmx10g -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:ConcGCThreads=2
What I'm seeing in the JVM heap free % graph for 24 hours is basically heap free % goes down at a slow rate until we hit about 9% (takes about 24 hours). Then the system is running what looks like a full gc and gets back to 97%.
Is there some setting I should add/modify that will tell the JVM to do this full GC sooner than when we get below 10% heap free? e.g. some ratio setting?
Its not causing problems that it waits until we get to 9% free, but it makes monitoring/alerting more difficult. Ideally we want to stay higher than say 30% free at all times so that if we drop down to those single digit numbers, we know there is some sort of problem e.g. memory leak.
Found the answer using a combination of other stackoverflow articles.
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=N
where N is roughly what percentage occupied will trigger a full GC. Default is ~92, which is why I am seeing full GC's at 9% free. Switching it to 65 worked for my use case. A full GC happens ~ 35% free now.
这篇关于为什么垃圾收集器不能比单数位堆免费更快地进行更积极的垃圾收集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！