我正在分析来自10个节点组成的集群的垃圾收集器（使用HotSpot VM）的日志。我正在使用并行GC用于年轻一代和Concurrent Mark Sweep用于旧版本。
所有节点中的日志都相似，因此以下数据来自GCViewer报告的节点1：
摘要
总时间：~14小时
吞吐量：99,49％
完整gc暂停次数：7
gc暂停次数：4722
GC性能：36.958,8M / s
内存
总堆（用量/最大值）：6.347,9M（79.7％）/ 7.967M
终身堆（使用/最大）：4.457M（75％）/ 5.942M
Young Heap（使用/最大）：2.025M（100％）/ 2.025M
完全GC释放：13.539,5M（0.2％）
GC释放：8.367.939,6M（99,8％）
InitiatinOccFraction（avg / max）：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％/ max：38,3％）。 Mark Sweep的初始标记可能会很快开始？增加此属性的最小阈值（CMSInitiatingOccupancyFraction）有什么好处？ 最后一点，在我看来，Full GC并没有在旧一代空间中释放太多内存。完全GC释放：13.539,5M（0.2％）。如果发生这种情况，这意味着我有需要长时间使用的对象，唯一的解决方案是增加旧代的堆空间？
您是否看到这些报告存在明显问题？
答案 0 :(得分：3)
我认为以下是不好的事情，
完整gc暂停次数：7
理想情况下应为0且实际上最小。
总计：226,41s（85,6％）
GC时间非常长，这意味着GC活动经常发生。
终身堆（使用/最大）：4.457M（75％）/ 5.942M
年轻堆（用量/最大值）：2.025M（100％）/ 2.025M
我认为你应该尝试增加你的年轻一代。 此外，检查GC策略还可以帮助您提高性能并适合您的应用程序。 还可以尝试使用GC参数来最小化GC暂停，即并行GC线程数等。