CentOS Tomcat日志中GC问题怎么解决 - 问答

CentOS 上 Tomcat 出现 GC 问题的定位与解决

一快速定位与监控

开启并滚动 GC 日志（推荐写入 Tomcat 日志目录，便于集中管理）

在 $CATALINA_HOME/bin/ 创建或编辑 setenv.sh，加入如下内容（按你的 JDK 版本选择其一）：

JDK 8（经典日志）：

export CATALINA_OPTS="\
-Xms2g -Xmx2g \
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails \
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime \
-XX:+PrintHeapAtGC \
-Xloggc:/var/log/tomcat/gc-$(date +%F).log"

JDK 9+（统一日志，推荐）：

export CATALINA_OPTS="\
-Xms2g -Xmx2g \
-Xlog:gc*:file=/var/log/tomcat/gc-%t.log:time,uptime,level,tags:filecount=10,filesize=10m"

说明：日志目录需可写（如 /var/log/tomcat/），并建议按天切割，便于分析。

配置 logrotate 切割 GC 日志（/etc/logrotate.d/tomcat-gc）：

/var/log/tomcat/gc-*.log {
  daily
  rotate 30
  missingok
  compress
  copytruncate
}

实时监控与排查
- 查看进程：ps -ef | grep tomcat；获取 PID。
- 观察 GC 概况：jstat -gcutil 1000（关注 YGC/YGCT、FGC/FGCT、O（老年代使用率））。
- 堆与对象：jmap -heap ；jmap -histo:live （必要时 jmap -dump:live,format=b,file=heap.hprof 导出后用 MAT 分析）。
- 线程与锁：jstack | grep -A 20 BLOCKED（定位阻塞与竞争）。

二常见症状与对应处理

症状 1：Young GC 每分钟上百次、接口抖动明显
- 典型原因：新生代过小，短期对象很快晋升老年代，引发频繁 Full GC。
- 处理要点：增大新生代（如 -Xmn 或 -XX:NewRatio），让对象在年轻代尽量回收；案例显示把新生代从 256MB 提升到约 600MB 后，Old 增长变慢、Full GC 显著减少。
症状 2：CMS 的 Remark 阶段 STW 过长（秒级卡顿）
- 处理要点：在 Remark 前主动触发一次 Minor GC，减少需扫描对象；启用可中断预清理；必要时提高并行线程数。
- 参考参数（JDK 8 + CMS）：
```
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=70
-XX:+CMSScavengeBeforeRemark
```
- 说明：CMS 已进入维护模式，若条件允许，优先迁移到 G1/ZGC。
症状 3：日志出现 “GC overhead limit exceeded”
- 含义：JVM 长时间 GC 却只回收极少内存（>98% 时间回收 <2% 堆），通常是内存不足或对象晋升过快。
- 处理要点：先查根因（泄漏/晋升过快/配置过小），不要仅用开关掩盖问题；临时过渡可用 -XX:-UseGCOverheadLimit，并配合 -XX:+DisableExplicitGC 禁止业务代码 System.gc() 触发；根本方案仍是调大堆或优化对象生命周期。
症状 4：周期性卡顿（如每周固定时段）
- 排查思路：优先核对该时段是否有 定时任务/报表/备份/缓存预热 等批处理集中执行，再结合 GC、线程、数据库慢查询综合判断；必要时将批处理错峰或限流。

三参数模板与落地步骤

基线模板（按场景选用，先备份再变更，逐步迭代）

JDK 8 + CMS（兼容性好，注意 CMS 维护状态）

CATALINA_OPTS="\
-Xms4g -Xmx4g \
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC \
-XX:CMSInitiatingOccupancyFraction=70 \
-XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark \
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails \
-XX:+PrintGCApplicationStoppedTime \
-Xloggc:/var/log/tomcat/gc-$(date +%F).log"

JDK 9+（推荐 G1，适合大堆与低停顿诉求）

CATALINA_OPTS="\
-Xms4g -Xmx4g \
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
-XX:InitiatingHeapOccupancyPercent=70 \
-Xlog:gc*:file=/var/log/tomcat/gc-%t.log:time,uptime,level,tags:filecount=10,filesize=10m"

落地步骤
1. 采集 1–2 天稳定期 GC 日志与 jstat 数据，确定目标（如 FGC ≤ 1 次/小时、单次 STW < 200ms）。
2. 依据“活跃数据”设定堆与新生代：稳定后做一次 Full GC，取老年代占用作为活跃数据 S；初始总堆可试 S×3~4，新生代 S×1~1.5，再按观测微调。
3. 只变更一台实例 A/B 对比，观察 YGC/FGC 频率与耗时、STW、吞吐量、错误率，确认收益后再全量发布。
4. 若发现对象生命周期异常或泄漏，结合 heap dump 与代码审查治理根因，参数优化只是缓解手段。

四实用工具与排错清单

日志分析：GCViewer、GCHisto、GCLogViewer、HPjmeter、garbagecat（对比不同日志、看吞吐与停顿趋势）。
运行时诊断：jstat -gcutil、jmap -heap/histo/dump、jstack、VisualVM/VisualGC（远程 JMX 可选）。
快速检查清单
- GC 日志是否开启且按天滚动；目录与权限是否正确。
- 是否存在业务代码 System.gc()（可用 -XX:+DisableExplicitGC 规避，但应先排查调用来源）。
- 老年代是否持续增长且 Full GC 后回收效果差（疑似泄漏或晋升过快）。
- 线程是否大量 BLOCKED（同步锁竞争/数据库/外部依赖瓶颈）。
- 是否存在定时批处理在固定时段放大 GC 与数据库压力。

0 赞

0 踩