在 GCViewer 的帮助下调整垃圾收集器

Question

我正在分析由 10 个节点组成的集群的垃圾收集器（使用 HotSpot VM）的日志。我对年轻一代使用并行 GC，对老一代使用 Concurrent Mark Sweep。

所有节点的日志都差不多，所以下面的数据来自GCViewer报告的节点1：

总结

总时间：~14h

吞吐量：99.49%

完全 gc 暂停的次数：7

gc 暂停次数：4722

GC 性能：36.958,8M/s

内存

总堆（使用/最大值）：6.347,9M (79.7%) / 7.967M

老堆（使用/最大值）：4.457M (75%) / 5.942M

年轻堆（使用/最大值）：2.025M (100%) / 2.025M

由完整的 GC 释放：13.539,5M (0.2%)

被 GC 释放：8.367.939,6M (99,8%)

InitiatinOccFraction（平均/最大值）：16.1%/38.3%

总推广：12.678,919M

暂停

完全 GC 暂停：7

最小/最大完全 gc 暂停：~0,5s / 8.2s

总计：38.11 秒 (14.4%)

GC 暂停：4722

最小/最大完全 gc 暂停：~0,00007s / 1.06s

总计：226.41 秒 (85.6%)

从这个数据我认为GC的性能还不错。吞吐量始终高于 99.1%。与完整 GC 相比，我们有更多的低暂停，这也是可取的。

从我的角度来看，我们有一个系统每 2 小时或多或少地执行一次完整的 GC，在此期间花费在 GC 上的时间约为 260 秒（完整的 GC 暂停时间 + 低暂停时间）。终身堆似乎不是问题，永远不会太满，尽管年轻堆总是满的。

我看到的唯一不好的是年轻堆总是满的，因此，执行了太多低暂停。但是，增加这个堆肯定会增加 GC 低暂停的时间，这是不可取的。 另一个问题与 InitiatinOccFraction 值有关（平均：16.1%/最大值：38.3%）。 Mark Sweep 初始标记可能开始得太早了？增加此属性的最小阈值 (CMSInitiatingOccupancyFraction) 有什么好处？ 最后一个，在我看来，Full GC 并没有在老年代空间释放太多内存。由完整 GC 释放：13.539,5M (0.2%)。如果发生这种情况，这意味着我有需要长寿的对象，唯一的解决方案是增加老年代的堆空间？

您认为这些报告有什么明显的问题吗？

Answer 1

我认为以下是不好的地方，

完全 gc 暂停次数：7

理想情况下应该是 0 并且在实践中应该是最小的。

总计：226,41s (85,6%)

GC 时间非常长，这意味着 GC 活动频繁发生。

老堆（使用/最大值）：4.457M (75%) / 5.942M

年轻堆（使用/最大值）：2.025M (100%) / 2.025M

我认为您应该尝试再增加一点年轻代的规模。 此外检查 GC 策略，这将帮助您提高性能并适合您的应用程序。 还可以尝试使用 GC 参数来最小化 GC 暂停，即并行 GC 线程的数量等。