Java:如何跟踪/监控CMS垃圾收集器的GC时间？
我想不出一种方法来监控JVM中的内存耗尽问题。
使用串行GC，我们只需查看完整的GC暂停时间，就可以很好地了解JVM是否出现了问题(例如，如果花费的时间超过几秒钟)。
CMS的表现似乎有所不同。
当从java.lang:type=GarbageCollector,name=ConcurrentMarkSweep MXBean (通过JMX)查询lastGcInfo时，报告的持续时间是所有GC步骤的总和，并且通常是几秒钟长。这并不表明GC有问题，相反，我发现太短的GC时间通常更多地是问题的指示器(例如，如果JVM进入CMS-concurrent-mark-start-> concurrent mode failure循环，就会发生这种情况)。
我也尝试过jstat，它给出了垃圾收集所用的累积时间(不确定它是用于旧的还是新的GC)。这可以用图表表示，但用于监视目的并不容易。例如，我可以解析jstat -gccause输出并计算随时间的差异，并对其进行trace+monitor (例如，在过去X分钟内花费在GC上的时间量)。
我使用以下JVM参数进行GC日志记录：
-Xloggc:/xxx/gc.log
-XX:+PrintGCDetails
-verbose:gc
-XX:+PrintGCDateStamps
-XX:+PrintReferenceGC
-XX:+PrintPromotionFailure如果没有其他方法可用，也可以选择解析gc.log，但最好的解决方案是使用java原生方法来获取相关信息。
信息必须是机器可读的(以便发送到监控平台)，因此不能使用可视化工具。我运行的是一个混合了JDK 6/7/8实例的生产环境，因此与版本无关的解决方案更好。
有没有一种简单的方法来监控CMS垃圾收集？我应该看什么指标？
回答 2
Stack Overflow用户
发布于 2017-03-31 20:04:44
从根本上说，我们需要从CMS并发收集器中获得两样东西
- 并发周期的吞吐量以跟上升级率，即每单位时间存活到旧一代的对象
- 旧一代中有足够的空间供并发周期
期间升级的对象使用
因此，假设IHOP固定为70%，那么当它在某个时刻达到>90%时，您可能会遇到问题。也许更早，如果你做了一些不适合年轻一代或超过他们的大型分配(这完全是特定于应用程序的)。此外，您通常希望它在并发周期之外花费比在其中更多的时间，尽管这取决于您调整收集器的紧密程度，原则上您可以让并发周期几乎一直在运行，但这样您就会有非常小的吞吐量余量，并在并发收集上消耗大量CPU时间。
如果你真的想要避免偶尔的完整GC，那么你将需要更多的安全余量，因为碎片(CMS是非紧凑的)。我认为这不能通过MX bean来监控，你必须启用一些特定于CMS的GC日志记录来获取碎片信息。
Stack Overflow用户
发布于 2017-03-31 20:13:16
用于查看GC日志:如果您已经启用了GC日志记录，我建议使用GCViewer -这是一个开源工具，可用于查看GC日志和查看诸如吞吐量、暂停时间等参数。
分析:我没有看到问题中提到的JDK版本。对于JDK 6，我建议使用visualvm来分析应用程序。对于JDK 7/8，我建议使用任务控制。您可以在JDK\lib文件夹中找到这些文件。这些工具可用于查看应用程序在一段时间内和GC期间的性能(可以通过visualvm UI触发GC )。
https://stackoverflow.com/questions/43138847
复制相似问题
腾讯云开发者
