8

对于不应暂停超过 200 毫秒的软实时系统的上下文，我们正在寻找一种在 Full GC 迫在眉睫之前发出预警的方法。我们意识到我们可能无法避免它，但我们希望在系统停止之前故障转移到另一个节点。

我们已经能够提出一个方案，在即将到来的完全 GC 之前为我们提供预先警告，这可能会导致系统停顿几秒钟（我们需要避免这种情况）。

我们能够提出的依赖于 CMS 空闲列表统计信息：-XX:PrintFLSStatistics=1. 这会在每个 GC 周期（包括年轻 GC）之后将空闲列表统计信息打印到 GC 日志中，因此该信息在很短的时间间隔内可用，并且在内存分配率较高的时间间隔内会更频繁地出现。就性能而言，它可能会花费一些成本，但我们的工作假设是我们可以负担得起。

日志的输出如下所示：

Statistics for BinaryTreeDictionary:
------------------------------------
Total Free Space: 382153298
Max   Chunk Size: 382064598
Number of Blocks: 28
Av.  Block  Size: 13648332
Tree      Height: 8

特别是，最大空闲块大小为 382064598 个字。对于 64 位字，这应该刚好低于 2915MB。这个数字一直在非常缓慢地下降，以大约每小时 1MB 的速度下降。

我们的理解是，只要最大空闲块大小大于年轻代（假设没有巨大的对象分配），每个对象提升都应该成功。

最近，我们进行了为期数天的压力测试，发现 CMS 能够将最大块大小保持在旧区域总空间的 94% 以上。最大空闲块大小似乎以小于 1MB/小时的速度减少，这应该没问题——据此我们不会很快达到完全 GC，并且服务器可能会因维护而停机比完全 GC 更频繁地发生。

在之前的测试中，在系统内存效率较低的时候，我们已经能够运行系统长达 10 个小时。在第一个小时内，最大空闲块大小已降至 100MB，并保持了 8 多个小时。在运行的最后 40 分钟内，最大空闲块大小以稳定的速度减少到 0，此时发生了完整的 GC——这非常令人鼓舞，因为对于那个工作负载，我们似乎能够提前 40 分钟警告（当块大小开始稳步下降到 0 时）。

我的问题是：假设这一切都反映了长时间的峰值工作量（生产中任何给定时间点的工作量只会更低），这听起来像是一种有效的方法吗？您认为我们应该能够从 GC 日志中获得最大空闲块大小统计信息的可靠性到什么程度？

我们绝对愿意接受建议，但要求它们仅限于 HotSpot 上可用的解决方案（至少目前对我们来说没有 Azul）。此外，G1 本身并不是解决方案，除非我们能提出一个类似的指标，在​​ Full GC 或任何显着超过我们 SLA 的 GC 之前给我们提前警告（这些情况偶尔会发生）。

4

2 回答 2

2

我在这里发布了来自 Oracle 的 Jon Masamitsu 的一个非常有启发性和令人鼓舞的答案的相关摘录，我从 HotSpot GC 邮件列表 (hotspot-gc-use@openjdk.java.net) 获得了该答案——他在 HotSpot 工作，所以这是确实是个好消息。

无论如何，这个问题现在仍然悬而未决（我不能相信自己引用了一封电子邮件:-)），所以请添加您的建议！

格式：原始帖子中的引用比乔恩的回应缩进更多。

我们的理解是，只要最大空闲块大小大于年轻代（假设没有巨大的对象分配），每个对象提升都应该成功。

这在很大程度上是正确的。在某些情况下，从年轻代提升到 CMS 代的对象在 CMS 代中需要比在年轻代中更多的空间。我认为这在很大程度上不会发生。

上面的内容非常令人鼓舞，因为我们绝对可以使用一些备用内存来防止他描述的罕见情况，而且听起来我们会做得很好。

<--剪辑-->

我的问题是：假设这一切都反映了长时间的峰值工作量（生产中任何给定时间点的工作量只会更低），这听起来像是一种有效的方法吗？您认为我们应该能够从 GC 日志中获得最大空闲块大小统计信息的可靠性到什么程度？

最大空闲块大小在 GC 打印它时是准确的，但在您阅读它并做出决定时它可能已经过时了。

对于我们的工作负载，这个指标处于非常缓慢的下降趋势，所以一点陈旧不会对我们造成伤害。

<--剪辑-->

我们绝对愿意接受建议，但要求它们仅限于 HotSpot 上可用的解决方案（至少目前对我们来说没有 Azul）。此外，G1 本身并不是解决方案，除非我们能提出一个类似的指标，在​​ Full GC 或任何显着超过我们 SLA 的 GC 之前给我们提前警告（这些情况偶尔会发生）。

我认为使用最大空闲块大小作为指标是一个不错的选择。它非常保守（听起来像您想要的那样）并且不受对象大小的奇怪混合的影响。

对于 G1，我认为您可以使用完全免费区域的数量。我不知道它目前是否打印在任何日志中，但它可能是我们维护（或很容易）的指标。如果完全空闲区域的数量随着时间的推移而减少，则可能表明即将进行完整的 GC。

乔恩

谢谢乔恩！

于 2013-04-29T22:30:58.900 回答
0

分而治之！

您的系统使用大量内存，并且需要具有高响应性。所以重新设计你的系统架构，实现展位。

识别关键的实时任务并使用其业务规则为其创建 Java 流程。并在其上使用了任何非常规的编程实践，其想法是不依赖 GC 来保持内存清洁。想一想，并发挥创造力。

现在创建其他层和流程，处理其余部分，并构建管道代码以连接所有内容。

甚至您也可以安排实时进程的生命周期，或检查它们的响应时间，以杀死它并创建一个新的进程。但我可以预期你不需要杀死它，以保持它的高响应。

祝你好运！

于 2013-04-29T19:55:07.200 回答