GC日志分析工具-GCeasy解析

一款新的GC日志分析仪器，业界首个基于人工智能机器学习指导的垃圾收集日志分析工具。 GCeasy具有内置的智能功能，可以自动检测JVM和Android GC日志中的问题并为之推荐解决方案。其具有以下特征：

1、能够在数秒内解决Java虚拟机内存和GC问题

2、能够给予JVM Heap设置建议

3、基于机器学习算法

基于GCeasy工具，我们可以达到如下效果：

1、解决内存泄漏问题

GCeasy的高级机器学习算法节省了处理神秘的GC日志的时间和麻烦。我们可以快速检测内存泄漏，长时间的GC暂停，过早的对象升级以及许多其他影响性能的问题。

2、在几秒钟内调整Java GC设置

强大的工具，可调整应用程序的内存和GC设置。该报告的“关键绩效指标”和“ GC统计数据”部分可帮助我们进行优化指导。

3、惊人的内存可视化器

视觉始于可视化，GCeasy日志分析报告中能够丰富地显示行业专家对此应用场景下Java内存建模的建议或观点。

作为一种通用型Java GC查看/分析器，其几乎支持所有的垃圾回收策略，包括串行GC、并行GC、CMS GC、G1 GC、ZGC以及其他等等。覆盖了Oracle、IBM、HP、Azul、OpenJDK以及其他等JVM提供商并支持所有的JDK版本，从最初的1.2到现在的15。不仅如此，GCeasy还支持统一GC日志记录格式，能够支撑可运行Java应用的所有平台环境，可以认为是一款全能型Java虚拟机垃圾回收日志分析工具。

除此之外，GCeasy根据我们所传递的GC算法、Java版本、JVM提供程序和内存参数，其可以灵活地展现不同场景下的GC日志格式，方便不同人群的视觉需求，让大家更容易理解。GCeasy是业界第一台在线GC日志分析器，可以支撑分析任何格式的GC日志，并且，我们可借助其所开放的RESTful API来分析垃圾收集日志。

以下为此工具的相关分析效果视图：

• Java内存大小信息

• 关键评价指标

• 交互图

• G1 收集阶段统计

• GC原因

• 命令行标志

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/wsm-admin/gc.log -XX:InitialHeapSize=8589934592 -XX:MaxHeapSize=8589934592 -XX:MaxMetaspaceSize=419430400 -XX:NativeMemoryTracking=detail -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC      

• 推荐建议

此处主要包含2部分内容，GC日志解析以及给予的解决策略，以下为简要参考：

（1）现象分析：

GC暂停时间的14.68％（即5秒59毫秒）是由“ G1巨大分配”事件触发的。大量分配是大于G1中区域大小的50％的分配。频繁的大量分配会导致几个性能问题：

1、如果区域包含巨大物体，则该区域中最后一个巨大物体与区域末端之间的空间将不被使用。如果有多个这样的庞大对象，那么这个未使用的空间可能导致堆变得碎片化。

2、在Java 1.8 u40之前，仅在完全GC事件期间才完成大型区域的回收。与在更新的JVM中一样，清除大型对象是在清理阶段完成的。

解决方案：

增加G1区域的大小，以使分配不会超过50％的限制。默认情况下，区域大小是在启动期间根据堆大小计算的。可以通过指定"-XX:G1HeapRegionSize"参数属性来覆盖它。区域大小必须介于1到32兆字节之间，并且必须是2的幂。

注意：增加区域大小是敏感的调整，因为它将减少区域数。因此，在增加新区域的大小之前，请进行彻底的测试。

（2）现象分析：

"疏散失败"事件触发了11.4％的GC暂停时间（即3秒953毫秒）。如果没有更多的空闲区域可以升级到老一代或复制到幸存者空间，并且由于堆已经处于最大状态而无法扩展，则会发生疏散失败。对于G1 GC，疏散失败需要花费较高的代价。

解决方案：

1、过度调整可能会导致疏散失败。因此，请消除所有与内存相关的属性，并仅保留最小和最大堆以及实际的暂停时间目标（即，仅使用-Xms、-Xmx和暂停时间目标-XX:MaxGCPauseMillis）。删除所有其他堆大小，例如-Xmn、-XX:NewSize、-XX:MaxNewSize、-XX:SurvivorRatio等。

2、如果问题仍然存在，增加JVM堆大小（即-Xmx）。

3、如果无法增加堆大小，并且如果注意到标记周期还没有开始到足够早的时间来收回旧的一代，则减少参数"-XX:InitiatingHeapOccupancyPercent"。默认值为45％。减小该值将更早开始标记循环。另一方面，如果标记周期较早开始而不是回收，则将"-XX:InitiatingHeapOccupancyPercent"参数阈值提高到默认值以上。

4、可以增加"-XX:ConcGCThreads"参数的值以增加并行标记线程的数量。增加并发标记线程将使垃圾回收运行更快。

5、增加"-XX:G1ReservePercent"参数的值。默认值为10％。这意味着G1垃圾收集器将尝试始终保持10％的可用内存。当您尝试增加此值时，GC将更早触发，以防止撤离暂停。 注意：G1 GC将此值的上限限制为50％。

（3）现象分析：

元数据GC阈值事件触发了GC暂停时间的0.19％（即63.9 ms）。在两种情况下会触发此类GC事件：

1、配置的元空间大小太小，无法满足实际需求

2、存在类加载器泄漏（极不可能，但可能）。

解决方案：

可以考虑将"-XX:MetaspaceSize"设置为更高的值。如果此属性尚不存在，请对其进行配置。将"-XX:MetaspaceSize"设置为较高的值将降低“元数据GC阈值”的频率。如果仍然看到报告“元数据GC阈值”事件，则需要从应用程序中捕获堆转储并进行分析。

借助此文章，我们可以学习如何进行堆转储分析。如果我们的应用正在Java 8 update 20及更高版本上运行，则可以考虑将"-XX:+ UseStringDeduplication"参数配置到应用程序中。它将帮我们删除应用程序中的重复字符串，并有可能提高整个应用程序的性能。