Java CMS GC 行为

Java CMS GC Behaviours

提问by Erdin? Ta?k?n

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.

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

-XX:+UseConcMarkSweepGC

-Xmx1172M

-Xms600M

-XX:+UseParNewGC

-XX:NewSize=150M

-XX:+UseConcMarkSweepGC

-Xmx1172M

-Xms600M

-XX:+UseParNewGC

-XX:NewSize=150M

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).

我的应用程序在带有 Java 1.6.0_21 的 SunOS 10 上运行。硬件是 2 x CPU 四核（uname -X 结果是 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.

观察 GC 行为，在 eden 空间上创建新对象直到 eden 已满。当 eden space full GC 运行时，清除垃圾，如果对象不是死复制到 Old-gen（我丢弃 'from' & 'to' 空格），同样 Old-Gen 已满，GC 以 CMS-concurrent 阶段运行并清除 Old -gen 空间。CMS 的某些部分是 Stop-the-world（暂停时间）。这是一个循环。

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 :)

1. 上面的风景是真的吗？
2. GC清理老一代空间后，没有足够的空间扩展老一代空间（XMS和XMS值不同）？
3. 全GC操作什么时候开始？如何决定呢？
4. CMS 并发阶段持续时间取决于 Eden 空间大小，实际上我的期望是，Eden 空间不会影响 CMS 并发阶段持续时间。与 CMS 并发阶段的 eden 空间相关的 GC 正在发生什么？
5. 还有什么建议我尽量减少暂停时间？确实，对我来说最有价值的答案:)

Thanks

谢谢

回答by Matt

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.

使用 CMS 时，您不能只是忽略幸存者空间。CMS 不是压缩收集器，这意味着如果您（或 JVM）错误地设置了tenuring 阈值，那么您将缓慢地将对象注入tenured 中，这将增加tenured 片段的速率，这将提前CMS 被强制执行的时间，因为它没有足够的连续可用空间来处理从幸存者空间到终身制的提升，这将强制执行一个完整的 gc 循环而没有预先警告，因此它是 1 STW 暂停中的全部内容。这需要多长时间取决于您的堆的大小，但很有可能发生一件事，它比普通的 eden 集合长几个数量级。

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:+PrintTenuringDistributionor you can just watch it with visualgc like you've done
5. You can then tune this with -XX:SurvivorRatioto control the size of the survivor spaces relative to eden and -XX:MaxTenuringThresholdto control how often an object can survive a young collection before it is tenured
6. -XX:CMSInitiatingOccupancyFractioncan 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)

1. STW 停顿不仅来自 CMS，也来自年轻代收集器
2. CMS 有 2 个 STW 阶段（标记和备注）和 3-4 个并发阶段，第一个 STW 阶段（标记）是严格的单线程，这可能会导致问题（此处的示例讨论）
3. 您可以控制处理并发阶段的线程数
4. 您需要了解对象倾向于存活多长时间，这可能意味着使用-XX:+PrintTenuringDistribution或者您可以像以前一样使用visualgc 观看它
5. 然后你可以调整它-XX:SurvivorRatio来控制相对于 eden 的幸存者空间的大小，并-XX:MaxTenuringThreshold控制一个对象在它被终身使用之前可以在年轻集合中存活的频率
6. -XX:CMSInitiatingOccupancyFraction可用于指导 CMS 在开始 CMS 阶段之前它需要多满（弄错了，你会暂停得很厉害）

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.

关于内部结构的摘要信息的一个很好的来源是Jon Masamitsu 的博客。关于此的另一个很好的介绍是HotSpot Java VM 中的 GC 调优。

回答by Peter Lawrey

The best way to minimise the impact of GC is to minise the number of object object you create. This is not always easy to do or the best solution overall, but it will minimise the GC pauses.

最小化 GC 影响的最佳方法是最小化您创建的对象对象的数量。这并不总是容易做到或总体上最好的解决方案，但它会最大限度地减少 GC 暂停。

If you can't produce less objects, try to make them short lived enough and the eden space large enough that they don't leave the eden space. (Or make the very long lived and re-used)

如果你不能生产更少的物体，试着让它们的寿命足够短，并且伊甸空间足够大，以至于它们不会离开伊甸空间。（或使寿命很长并重新使用）

1. There are three spaces to worry about here, eden -> survivor -> tenured http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

2. The GC tries to ensure there is enough free space after a full GC and the -msand -mxoptions do control how large they will be (former known as -Xmsand -Xmx)

3. A full GC starts when the tenured space is full, or the suvivor space is exhaused (e.g. there are too many object copied from the eden space) or the CMS desices now is a good tile to try and do a concurrent cleanup.

4. The CMS only cleans up the tenured space.

5. See my previous answers.

1. 这里需要担心三个空间，eden ->survivor->tenured http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

2. GC 尝试确保在完整 GC 后有足够的可用空间，并且-msand-mx选项确实控制它们的大小（以前称为-Xmsand -Xmx）

3. 当tenured空间已满，或suvivor空间已用尽（例如，从伊甸园空间复制的对象太多）或CMS desices现在是一个尝试并发清理的好瓷砖时，将启动full GC。

4. CMS 只清理永久空间。

5. 看我之前的回答。