产品动态
GC 日志分析
GC 日志分析功能基于 JVM 输出的 GC Log 排查有可能影响应用性能的潜在风险。
前提条件
腾讯云增强版 Java 探针2.3-20240831以上版本支持 GC 日志分析功能。
在使用此功能前，先确保 JVM 已经配置了打印 GC 日志相关的启动参数。
打印 GC 日志相关的启动参数
Java 8
启动参数示例如下：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:GCLogFileSize=20M -XX:NumberOfGCLogFiles=5必填参数：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XloggcJava 9及以上版本
启动参数示例如下：
-Xlog:gc*:file=gc_%p_%t.log:time,pid:filecount=5,filesize=20M或者直接指定GC日志绝对路径：
-Xlog:gc*:file=/path/to/gc.log:time,pid:filecount=5,filesize=20M其中：file 为必填参数，用于指定 GC 日志文件路径。
说明：
操作步骤
1. 登录 腾讯云可观测平台。
2. 在左侧菜单栏选择应用性能监控 > 应用诊断，然后选择进入 GC 日志分析页面。
3. 在页面左侧的实例列表中找到需要进行 GC 日志分析的实例，单击分析，在弹出对话框中选择数据时长，数据时长代表从 GC 日志中向回溯的时间跨度，然后单击确认。
4. 分析总耗时为数秒至5分钟左右，取决于当前选择数据时长内所包含的 GC 日志内容大小，应用性能监控最多可以分析100MB的 GC 日志数据，超出部分将被截断。
5. 在页面右侧表格中能够查到历史分析记录，分析完成的记录将展示为采集完成状态，单击查看报告获取分析结果。
分析报告解读
分析报告中包含三部分内容：
JVM 信息：目前仅支持在 JDK 8 中展示，记录 JVM 版本、启动参数、系统属性等信息。
GC 总览（Summary）：在选定时间段有 GC 行为时会展示。需要重点关注日志起始时间、GC 事件总数、GC 吞吐量等信息。GC 吞吐量是衡量 Java 垃圾回收器性能的重要指标，可以尝试不同的垃圾回收器，或者调整垃圾回收器的相关参数，以获取更低的 GC 次数以及更高的 GC 吞吐量。
分析结果（Analysis）：在选定时间段有 GC 行为时会展示。分析结果总结了 GC 方面可能存在的问题，并给出了问题的原因以及和解决建议，是分析报告的核心内容，需要重点关注结果分析中的 error 和 warn 部分。
参考如下分析报告：
GC 总览（Summary）
GC 事件总数（GC Events）：36586次。该数字偏高，可能意味着应用程序创建了大量的短暂对象，这可能会导致频繁的垃圾回收。
GC 事件类型（Event Types）：该时间内产生了 PAR_NEW、CMS_INITIAL_MARK、CMS_CONCURRENT、CMS_REMARK、CMS_SERIAL_OLD 这几种类型的 GC。
并行 GC 事件（Parallel Events）：36585次。
串行 GC 事件（Serial Events）：1次。
最大堆使用量（Heap Used Max）：7092037 K。
GC 后最大堆使用量（Heap After GC Max）：6988066 K。这个数字如果接近最大堆使用量（Heap Used Max），可能意味着应用程序的内存使用效率不高，或者存在内存泄漏。
最大堆分配量（Heap Allocation Max）：8371584 K。
元空间最大使用量（Metaspace Used Max）：167164 K。
GC 后元空间最大使用量（Metaspace After GC Max）：167164 K。
最大元空间分配量（Metaspace Allocation Max）：1204224 K。
GC 吞吐量（GC Throughput）：96%。这意味着应用程序在96%的时间内在执行实际的业务逻辑，而在4%的时间内在进行垃圾回收。GC 吞吐量是一个衡量 Java 垃圾回收器性能的指标，它表示的是应用程序运行的时间占总运行时间的百分比。
最大 GC 暂停时间（GC Pause Max）：7.528秒。如果单次 GC 的暂停时间过长，那么可能会影响应用程序的响应时间和延迟。例如，如果应用程序需要在1000毫秒内完成交易，那么任何一次 GC 暂停超过1000毫秒都是不可接受的。优化的方法可能包括使用并发垃圾回收器（如 G1或 CMS），这些垃圾回收器可以在应用程序运行的同时进行垃圾回收，从而减少 GC 暂停时间。
分析结果（Analysis）
分析结果（Analysis）总结了 GC 方面可能存在的问题，并给出了问题的原因以及和解决建议，需要重点关注结果分析中的 error 和 warn 部分。例如，在如下示例中，明确指出了 CMS_SERIAL_OLD 垃圾回收器是串行运行的，回收大内存的时候可能会需要非常长的时间，建议通过调整 JVM 参数避免使用串行垃圾回收器。您可以基于分析结果对 JVM 进行调优，并通过应用性能监控的实例监控等功能对比调优后的效果。
文档反馈