nad*_*vwr 8 java performance garbage-collection real-time
对于不应暂停超过200毫秒的软实时系统的环境,我们正在寻找一种在完全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
Run Code Online (Sandbox Code Playgroud)
特别是,最大空闲块大小为382064598个单词.使用64位字,这应该低于2915MB.这个数字一直在缓慢下降,速度大约为每小时1MB.
我们的理解是,只要最大空闲块大小大于年轻代(假设没有大量的对象分配),每个对象促销都应该成功.
最近,我们进行了为期数天的压力测试,并且已经看到CMS能够将最大块大小保持在旧区域总空间的94%以上.最大的免费块大小似乎以小于1MB /小时的速度递减,这应该没问题 - 据此我们不会很快就达到完全GC,并且服务器可能会因维护更多而停机经常比完整的GC可能发生.
在之前的测试中,当系统内存效率较低时,我们已经能够运行系统10小时.在第一个小时内,最大免费块大小减少到100MB,并且停留超过8小时.在运行的最后40分钟内,当一个完整的GC发生时,最大空闲块大小以稳定的速率向0降低 - 这非常令人鼓舞,因为对于那个工作负载,我们似乎能够提前40分钟警告(当块大小开始稳定下降为0时).
我的问题是:假设这一切都反映了长时间的峰值工作量(生产中任何给定时间点的工作量只会更低),这听起来像是一种有效的方法吗?您认为我们应该能够依靠GC日志中的最大空闲块大小统计量来确定可靠性的程度吗?
我们绝对愿意接受建议,但要求他们仅限于HotSpot上的解决方案(No Azul对我们来说,至少目前为止).此外,G1本身并不是解决方案,除非我们能够提出类似的指标,以便在Full GCs之前提前发出警告,或者任何明显超过我们SLA的GC(这些可能偶尔发生).
我在这里发布了来自 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 即将到来。
乔恩
谢谢乔恩!