如何在 Java GC 中自适应调整旧区域的大小?
为了调整 Java 6 (1.6.0_23) GC,我使用 -XX:+UseParallelOldGC
以及
-XX:+PrintTenuringDistribution
-XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveGCBoundary
我的目标是让 GC 计算新旧区域之间的最佳比率。然而,visualgc(jvmstat 3.0)显示,虽然伊甸园和幸存者之间的比率 根据我的工作负载进行修改,旧区域(绝望地)保持其初始大小,由 newRatio 固定(在我的例子中为 2)。
我的设置或期望有什么问题?
在我的屏幕上,经过 19 个集合后,visualgc 显示老一代始终低于 500m 而老一代的保留和承诺大小等于624m。 我已将 NewSize 设置为 30m,将 MaxNewSize 设置为 300m,但这不会改变任何内容:NewRatio 看似无形…… PrintAdaptiveSizePolicy 仅涉及幸存者。
重点是,visualgc 的“保留空间”菜单没有显示任何关于 Old Gen 空间的内容...... 我也尝试过使用 -XX:+UseAdaptiveGCBoundary 没有任何改变。
这是一些日志 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails
有一次full gc,以及堆的最终打印... 看来终身分配也是乱码......
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 182096K->66576K(233024K)] 681978K->631994K(932096K), 0.2582390 secs] [Times: user=0.29 sys=0.00, real=0.26 secs]
116.431: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 183120K->39952K(233024K)] 748538K->670910K(932096K), 0.1578620 secs] [Times: user=0.29 sys=0.00, real=0.16 secs]
116.589: [Full GC [PSYoungGen: 39952K->0K(233024K)] [ParOldGen: 630958K->310429K(699072K)] 670910K->310429K(932096K) [PSPermGen: 21973K->21973K(30592K)], 1.3326720 secs] [Times: user=1.79 sys=0.01, real=1.33 secs]
118.050: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 116544K->18448K(233024K)] 426973K->328877K(932096K), 0.0745320 secs] [Times: user=0.14 sys=0.00, real=0.08 secs]
118.234: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 134992K->24592K(233024K)] 445421K->351409K(932096K), 0.1290960 secs] [Times: user=0.14 sys=0.00, real=0.13 secs]
118.526: [GC
Desired survivor size 114884608 bytes, new threshold 1 (max 15)
[PSYoungGen: 141136K->36880K(237312K)] 467953K->380085K(936384K), 0.1187320 secs] [Times: user=0.21 sys=0.00, real=0.12 secs]
118.759: [GC
Desired survivor size 108593152 bytes, new threshold 1 (max 15)
[PSYoungGen: 142446K->40976K(233024K)] 485652K->416957K(932096K), 0.1153230 secs] [Times: user=0.23 sys=0.00, real=0.12 secs]
Heap
PSYoungGen total 233024K, used 97957K (0xb3a40000, 0x9e4f0000, 0x9e4f0000]
eden space 120832K, 47% used [0x9e4f0000,0xa1c95668,0xa5af0000)
from space 112192K, 36% used [0xa5af0000,0xa82f4020,0xac880000)
to space 106048K, 0% used [0xad2b0000,0xad2b0000,0xb3a40000)
ParOldGen total 699072K, used 375981K [0x73a40000, 0x9e4f0000, 0x9e4f0000)
object space 699072K, 53% used [0x73a40000,0x8a96b730,0x9e4f0000)
PSPermGen total 30592K, used 21981K [0x6fa40000, 0x71820000, 0x73a40000)
object space 30592K, 71% used [0x6fa40000,0x70fb7668,0x71820000)
For tuning the Java 6 (1.6.0_23) GC, I use -XX:+UseParallelOldGC
along with
-XX:+PrintTenuringDistribution
-XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveGCBoundary
My goal is to let the GC compute an optimal ratio between old and new regions. However, visualgc (jvmstat 3.0) shows that while the ratio between the eden and the survivors
is modified according to my workload, the old region remains (desperately) at its initial size, fixed by the newRatio
(2 in my case).
What is wrong with my settings or expectations?
On my screen, after 19 collections visualgc shows the old Gen constantly under 500m
while the reserved and committed sizes of the old Gen are equal to 624m.
I have set NewSize to 30m and MaxNewSize to 300m, but this does not change anything: NewRatio
seems untangible...
PrintAdaptiveSizePolicy only speaks about survivor.
The point is that the "reserved space" menu of visualgc does not show anything for the Old Gen space...
I have tryed also in using -XX:+UseAdaptiveGCBoundary
without any change.
Here are some logs-XX:+PrintTenuringDistribution -XX:+PrintGCDetails
There is a full gc, and the final print of the heap...
It seems that the tenured distribution is garbled, too...
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 182096K->66576K(233024K)] 681978K->631994K(932096K), 0.2582390 secs] [Times: user=0.29 sys=0.00, real=0.26 secs]
116.431: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 183120K->39952K(233024K)] 748538K->670910K(932096K), 0.1578620 secs] [Times: user=0.29 sys=0.00, real=0.16 secs]
116.589: [Full GC [PSYoungGen: 39952K->0K(233024K)] [ParOldGen: 630958K->310429K(699072K)] 670910K->310429K(932096K) [PSPermGen: 21973K->21973K(30592K)], 1.3326720 secs] [Times: user=1.79 sys=0.01, real=1.33 secs]
118.050: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 116544K->18448K(233024K)] 426973K->328877K(932096K), 0.0745320 secs] [Times: user=0.14 sys=0.00, real=0.08 secs]
118.234: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 134992K->24592K(233024K)] 445421K->351409K(932096K), 0.1290960 secs] [Times: user=0.14 sys=0.00, real=0.13 secs]
118.526: [GC
Desired survivor size 114884608 bytes, new threshold 1 (max 15)
[PSYoungGen: 141136K->36880K(237312K)] 467953K->380085K(936384K), 0.1187320 secs] [Times: user=0.21 sys=0.00, real=0.12 secs]
118.759: [GC
Desired survivor size 108593152 bytes, new threshold 1 (max 15)
[PSYoungGen: 142446K->40976K(233024K)] 485652K->416957K(932096K), 0.1153230 secs] [Times: user=0.23 sys=0.00, real=0.12 secs]
Heap
PSYoungGen total 233024K, used 97957K (0xb3a40000, 0x9e4f0000, 0x9e4f0000]
eden space 120832K, 47% used [0x9e4f0000,0xa1c95668,0xa5af0000)
from space 112192K, 36% used [0xa5af0000,0xa82f4020,0xac880000)
to space 106048K, 0% used [0xad2b0000,0xad2b0000,0xb3a40000)
ParOldGen total 699072K, used 375981K [0x73a40000, 0x9e4f0000, 0x9e4f0000)
object space 699072K, 53% used [0x73a40000,0x8a96b730,0x9e4f0000)
PSPermGen total 30592K, used 21981K [0x6fa40000, 0x71820000, 0x73a40000)
object space 30592K, 71% used [0x6fa40000,0x70fb7668,0x71820000)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为这是不可能的。 GC 有一组有限的“调谐旋钮”,我看不出有哪个可以为您做到这一点。我的感觉是你“想太多”这个问题。
参考:
如果这个答案不够好,那么您的选择相当有限:
如果您通过适当的渠道并准备花一些钱,您可能会从 Oracle 调优专家那里获得一些帮助.
如果您有时间和耐心,您可以尝试了解 OpenJDK 代码库中的 GC 源代码。
I don't think that it is possible. The GC has a limited set of "tuning knobs", and I can't see one that would do this for you. My feeling is that you are "over thinking" the problem.
Reference:
If this answer is not good enough, your options are rather limited:
If you went through the appropriate channels and were prepared to fork out some money, you could probably get some help from an Oracle tuning expert.
If you had the time and patience, you could try to get your head around the GC source code in the OpenJDK code-base.