大促老年代爆仓源于JVM内存压力集中释放，需结合GC日志、堆内存与业务日志交叉验证；OceanBase回收站高频DROP TABLE等操作会加剧Metaspace占用和Full GC频率。
大促期间老年代爆仓本质是JVM内存压力集中释放，必须结合GC日志、堆内存指标与业务日志交叉验证。回收日志（如OceanBase回收站操作记录）本身不直接反映JVM状态，但能辅助判断是否因误删表、频繁重建索引等操作引发异常GC行为——这类操作会显著增加元数据压力和Full GC频率。
抓取关键GC日志并过滤老年代事件
在应用节点执行以下命令，实时捕获含“Full GC”“Metaspace”“CMS”或“G1 Old Gen”的日志行：
- tail -f /path/to/gc.log | grep -E "(Full GC|Metaspace|Old Gen|concurrent mode failure)"
- 若使用G1，加参数过滤：grep -E "(GC pause.*old|to-space exhausted|evacuation failure)"
- 配合时间戳筛选大促窗口：sed -n '/2026-05-20 20:00:/, /2026-05-20 22:00:/p' gc.log | grep "Full GC"
关联回收日志排查元数据扰动源
OceanBase回收站操作（如DROP TABLE）会触发大量元数据变更，间接加剧Metaspace占用和GC压力。需检查对应时段是否有高频逻辑删除：
- 查回收站操作日志：grep "DROP TABLE" /home/admin/oceanbase/log/observer.log | awk '$3>"20:00:00" && $3
- 确认是否开启回收站：登录OBProxy执行 SHOW VARIABLES LIKE 'recyclebin';，若为OFF则DROP为物理删除，更易引发瞬时压力
- 比对时间轴：将GC峰值时间（如21:14:22）与回收站日志中DROP时间（如21:14:18）对齐，判断是否存在因果链
用jstat快速定位老年代水位与GC频次
无需重启，直接观测运行中JVM的老年代使用率和GC耗时：
-
jstat -gc -h10
2s ：每2秒输出一次，重点关注 OU（Old Used）、OC（Old Capacity）、FGCT（Full GC总耗时） - 若OU/OC持续 >90% 且FGCT线性上升，说明老年代已无法有效回收，需立即干预
- 结合jmap查看大对象：jmap -histo:live
| head -20，重点看byte[]、HashMap$Node、String等常见内存大户
联动SLS日志服务做上下文归因
将GC日志、应用业务日志、OceanBase审计日志统一接入SLS，用TraceId或时间窗口做跨源关联：
- 在SLS中构造查询：* | SELECT count(*) as cnt, avg(durationMs) FROM log WHERE __topic__ = 'gc-log' AND time >= '2026-05-20 20:00:00' GROUP BY date_trunc('minute', __time__) ORDER BY cnt DESC LIMIT 10
- 再查同一分钟内OceanBase审计日志：__topic__: ob_audit_log AND (operation: 'DROP' OR operation: 'CREATE INDEX') AND __time__ >= '2026-05-20 21:14:00'
- 若两组高峰重叠，基本可判定为元数据操作诱发GC风暴
