借助GCViewer优化垃圾收集器

Question

我在分析由10个节点组成的集群的垃圾回收器（使用HotSpot VM）的日志。我为年轻一代使用并行GC，并使用并发标记扫描旧的。

日志是在所有节点相似，所以下面的数据是从由GCViewer报告的节点1：

摘要

总时间：〜14小时

吞吐量：99， 49％

满GC暂停数：7

GC暂停数：4722

GC性能：36.958,8M /秒

内存

整个堆（使用/最大）：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,11s（14.4％）

GC暂停：4722

最小/最大全GC暂停：〜0,00007s/1.06s

总：226,41s（ 85,6％）

从这些数据中我认为GC的性能很好。吞吐量始终高于99.1％。我们比完整的GC有更多的低停顿时间，这也是可取的。从我的角度来看，我们有一个系统每2小时完成一次或多或少的一次完整的GC，并且在那段时间内用于GC的时间约为260秒（完整的GC暂停时间+低暂停时间）。终身堆似乎不是一个问题，永远不会太满，虽然年轻的堆总是满的。

我看到的唯一不好的事情是，年轻的堆总是满的，因此，太多的低停顿正在执行。但是，增加这个堆肯定会增加GC低停顿时间，这是不可取的。 另一个问题与InitiatinOccFraction值有关（平均值：16.1％/最大值：38.3％）。马克扫描初始标记可能开始过早？提高此属性的最小阈值（CMSInitiatingOccupancyFraction）的优点是什么？ 最后一个，在我看来，Full GC并没有在老一代空间中释放太多内存。完全GC解冻：13.5395M（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线程数量等。