Java CMS GC行为

问题描述

我有一个应用程序导致创建大量垃圾。首先（几乎是一个）标准是低的GC暂停时间。我使用visualgc工具（和gc日志）尝试不同的GC参数。
$ b

我的应用程序在带有Java 1.6.0_21的SunOS 10上运行。硬件是2个CPU四核心（uname -X结果是numCPU = 8）。

问题是

观察GC行为，在eden空间上创建新对象直到伊甸园已满。当eden space full GC运行时，清除垃圾，如果对象没有死亡复制到Old-gen（我从'&'丢弃''到'spaces），类似的Old-Gen已满，GC以CMS并发阶段运行并清除旧的空间。 CMS的某些部分是停止世界（暂停时间）。这是一个循环。

1. 上面的场景真实吗？


2. GC清理旧版空间后，空间扩大旧有空间（XMS和XMS值不同）？


3. 完整的GC操作何时开始？如何决定它？


4. CMS并发阶段持续时间取决于Eden空间大小，实际上我的预期是，Eden空间不会影响CMS并发阶段持续时间。什么是GC与CMS-concurrent阶段的eden空间相关？


5. 还有什么建议让我尽量减少暂停时间？确实，对我来说最有价值的答案是：）

谢谢

解决方案

使用CMS时，不能忽略幸存者空间。 CMS不是一个压缩收集器，这意味着如果你（或JVM）获得了错误的持续时间门槛，那么你会慢慢地将对象放入终身，这将增加终止片段的速率，这将导致CMS被强制的时间，因为它没有足够的连续可用空间可用于处理来自幸存者空间的促销活动，从而在没有预先警告的情况下强制执行完整的gc循环，因此这是1 STW暂停时的全部内容。这需要多长时间取决于你的堆的大小，但有一件事很有可能，它会比正常的伊甸园收藏更长的时间。

有一个

1. STW暂停不仅来自CMS，他们也来自年轻的收藏家。


2. CMS有2个STW阶段（标记和备注）和3-4个并发阶段，第1个STW阶段（标记）严格是单线程的，可能会导致问题（关于）


3. 您可以控制处理并发阶段的线程数量


4. 您需要了解对象倾向于生存多久，这可能意味着使用 -XX：+ PrintTenuringDistribution 或者你可以像使用visualgc一样观看它


5. 然后你可以用 -XX：SurvivorRatio 来控制survi的大小vor空间相对于eden和 -XX：MaxTenuringThreshold 来控制一个对象在一个年轻的集合中的存活频率


6. -XX：CMSInitiatingOccupancyFraction 可用于指导CMS在开始CMS阶段之前需要完成多少工作（弄错了这一点，否则你会停下来）

最终，您需要了解哪个收藏家正在暂停，多长时间一次，以及是否存在导致暂停的异常原因。然后，您需要将其与每一代的大小进行比较，看看您是否可以调整参数，以最大限度地减少暂停的次数（和/或持续时间）。

请记住，由于需要进行长时间运行的测试以确定它是否会随着时间的推移而恶化，因此这可能会缩短。此外，如果没有可重复的自动化工作负载，几乎无法得出关于您是否真正改进了事情的任何确切结论。

一个很好的关于内部结构是。另一个很好的介绍是。

I have an application that cause to creating lots of garbage. First (and almost one) criteria is low GC pause time. I try different GC parameters using visualgc tool (and gc logs). Best parameters are below.

My application run on SunOS 10 with Java 1.6.0_21 . Hardware is 2 x CPU quad core (uname -X result is numCPU = 8).

Questions are

Observing GC behaviours, New objects creating on eden space until eden is full. When eden space full GC runs, clear garbage, if object is not dead copy to Old-gen (I discard 'from' & 'to' spaces), Similarly Old-Gen is full, GC runs with CMS-concurrent phase and clear Old-gen space. Some part of CMS is Stop-the-world (pause time). This is a loop.

1. Is above scenerio true?
2. After GC clean old-gen space, there is no enough space expand old-gen space(XMS and XMS values are different) ?
3. When full GC operation start? How to decided it?
4. CMS-concurrent phase duration depends on Eden space size, actually my expectation is, Eden space does not effect CMS-concurrent phase duration. What is going on GC related with eden space on CMS-concurrent phase?
5. What else suggest to me minimizing pause time? Indeed, Most valuable answer for me :)

Thanks

解决方案

you can't just ignore the survivor spaces when using CMS. CMS is not a compacting collector which means that if you (or the JVM) gets the tenuring threshold wrong then you will slowly bleed objects into tenured which will increase the rate at which tenured fragments which will bring forward the time when CMS is forced because it has insufficient contiguous free space available to handle promotions from the survivor spaces into tenured which will force a full gc cycle with no advance warning and hence it's the full thing in 1 STW pause. How long this takes will depend on the size of your heap but one thing is highly likely, it will be orders of magnitude longer than a normal eden collection.

There are a few other things to note here;

1. STW pauses do not only come from CMS, they come from the young gen collector too
2. CMS has 2 STW phases (mark and remark) and 3-4 concurrent phases, the 1st STW phase (mark) is strictly singlethreaded which can cause issues (sample discussion on this here)
3. You can control the no of threads handling the concurrent phases
4. You need to understand how long objects tend to live for, this may mean use of -XX:+PrintTenuringDistribution or you can just watch it with visualgc like you've done
5. You can then tune this with -XX:SurvivorRatio to control the size of the survivor spaces relative to eden and -XX:MaxTenuringThreshold to control how often an object can survive a young collection before it is tenured
6. -XX:CMSInitiatingOccupancyFraction can be used to guide CMS as to how full it needs to be before it starts the CMS phase (get this wrong and you'll pause badly)

Ultimately you need to understand which collector is pausing, how often, for how long and whether there are any abnormal causes of that pause. You then need to compare this against the size of each generation to see whether you can tweak the parameters so as to minimise the number (and/or the duration) of pauses.

Bear in mind that this can be timesink due to the need for long running tests to see whether it deteriorates over time. Also without a repeatable, automated workload, it's nigh on impossible to draw any firm conclusions as to whether you've actually improved things.

One good source of summary info on the internals is Jon Masamitsu's blog. Another good presentation on this is GC Tuning in the HotSpot Java VM.

这篇关于Java CMS GC行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！