信创容器压测重启排查与JVM诊断配置实战

一、问题背景：信创环境下的容器化Java服务

随着信创改造的推进，不少团队把原本运行在传统x86服务器上的Java服务，整体迁移到“国产芯片＋国产操作系统＋容器云平台”的新技术栈上。CPU架构、内核版本、容器运行时都发生了变化，过去在传统环境里“默认正确”的JVM配置，在容器与信创系统组合的新环境里未必仍然成立。

我们遇到的问题非常有代表性：一个基于JDK 17的Java服务，功能验证一切正常，可一旦开始压测，1小时内必然重启。稳定性问题与性能问题（接口响应耗时过长）往往同时出现，本文以“重启”为主线，完整复盘排查与修复过程。

二、现象描述：从监控数据还原故障现场

通过容器云平台的监控视图，可以还原出完整的故障链路：

1. 进程消失：监控里Java进程的指标曲线突然中断，进程不复存在；
2. 健康检查失败：探针连续失败后，编排系统触发容器重建，表现为“服务重启”；
3. 重启前的资源曲线：CPU使用率打满100%，内存使用率高达98%以上且持续居高不下。

这三点组合起来，可以先把问题定性：这不是业务代码抛异常导致的崩溃，而是资源耗尽类问题。CPU与内存同时逼近极限，通常意味着JVM陷入了恶性循环——GC线程疯狂工作占满CPU，堆却始终回收不出来，业务线程大量阻塞，接口响应耗时随之恶化，最终探针超时或进程被系统终结。

容器场景下，“重启”背后一般有三种可能，需要在后续排查中逐一区分：

• JVM堆内OOM：抛出OutOfMemoryError，进程可能存活但已不可用；
• 容器内存超限：容器内存触到limit，被内核以SIGKILL强杀，JVM来不及做任何事；
• 探针超时被动重启：进程假死，编排系统按健康检查失败主动重建。

三、第一轮排查：为什么现场没有留下任何证据

3.1 检查清单

按照“先找证据、再谈根因”的原则，第一轮排查聚焦四类信息：

• 是否生成了heapdump（堆转储）文件；
• 是否有GC日志可以回放；
• 容器编排配置文件（探针、资源限额、挂载声明等）；
• 容器启动脚本中的JVM参数。

3.2 检查结果

结果一无所获：没有堆转储文件，也没有任何GC日志。顺着这条线索继续核查配置，找到了两个直接原因：

1. 启动脚本传入的JVM参数里，根本没有开启GC日志；
2. heapdump相关的输出路径并非容器挂载路径（即编排文件volumeMounts中声明的mountPath），而是容器内部的可写层目录。

第二个原因的杀伤力最大：容器一旦重建，可写层整体丢弃，哪怕dump文件曾经生成过，也会随旧容器一起消失。证据不是没产生，而是产生了也留不住。

3.3 反思：诊断配置必须在故障发生前就位

这次排查最大的教训是：问题定位的关键产物（堆转储、GC日志、错误日志）必须在故障发生之前就配置好。等故障出现后再补配置，只能等下一次故障“配合演出”。对压测这类可预期场景，诊断参数属于开工前的必备项，而非事后的补救项。

四、JVM诊断参数配置：给进程装上“黑匣子”

对启动脚本run.sh做了如下改造。核心原则只有一条：所有落盘路径必须位于容器编排文件中volumeMounts声明的挂载目录之内（下例为/logs），并借助命名空间、应用名、主机名等环境变量区分归属与实例。

# 发生OOM时，JVM立即终止退出，快速失败
-XX:+ExitOnOutOfMemoryError
# 发生OOM时生成Java堆转储
-XX:+HeapDumpOnOutOfMemoryError
# 堆转储保存位置（挂载路径＋应用信息＋时间戳，避免多实例覆盖）
-XX:HeapDumpPath=/logs/${POD_NAMESPACE}/${APP_NAME}/heapdump_start_$(date +"%Y-%m-%d_%H%M%S").hprof
# JVM致命错误日志保存位置（以主机名区分实例）
-XX:ErrorFile=/logs/${POD_NAMESPACE}/${APP_NAME}/${HOSTNAME}-hs_err_pid.$.log
# 开启GC日志：滚动保留5个文件，每个10M
-Xlog:gc*:file=/logs/${POD_NAMESPACE}/${APP_NAME}/gc-%t.log:hostname,time,uptime,pid:filecount=5,filesize=10M

逐条说明设计意图：

ExitOnOutOfMemoryError：把决策权交还给编排系统。 JVM在堆内OOM后往往并不会退出，而是带着“半死”状态继续运行：线程池耗尽、请求堆积、探针超时、接口耗时雪崩。与其让服务在这种状态下苟延残喘，不如收到OutOfMemoryError后立即退出，由容器平台按重启策略快速拉起一个干净实例，整体恢复时间反而更短。同时，明确的退出事件更容易与平台事件、退出码对应上，便于区分“JVM主动退出”与“被系统强杀”。

HeapDumpOnOutOfMemoryError＋HeapDumpPath：留住OOM瞬间。 堆转储是内存类问题最重要的分析材料。文件名嵌入时间戳，避免同一实例多次OOM互相覆盖；路径落在挂载卷上，容器重建也不会丢。

ErrorFile：兜底的致命错误日志。 当JVM因内部致命错误崩溃时，崩溃现场会写入该文件；文件名携带主机名，多副本场景下能快速对应到具体实例。

Xlog:gc*：统一日志框架的GC记录。 JDK 9以后GC日志通过-Xlog配置，gc*表示开启全部gc相关标签；文件名中的%t会展开为启动时间戳，多次重启的日志互不混杂；filecount=5,filesize=10M控制滚动保留策略，兼顾信息完整度与磁盘成本。有了GC日志，就能直接回答“重启前是否在疯狂Full GC、每次停顿多久”这类关键问题，把推测变成证据。

五、启动脚本改造：让诊断日志“可持续”

诊断参数就位后，还要防止日志本身演变成新故障。GC日志与各类组件日志长期累积，写满磁盘后轻则日志中断，重则触发节点磁盘压力、容器被驱逐。因此在start_java_server函数中追加一个轻量清理循环：

start_java_server() {
    echo "---- start java process ----"
    touch /app/bin/test.log
    eval java $JAVA_OPTS -jar $appname
    while true; do
        # 清理两天前的GC日志
        find "${LOG_PATH}" -mtime +2 -type f -name "*.log*" -exec rm {} \;
        # 清理7天前的消息组件故障转移日志目录（跳过本机实例目录）
        find "${LOG_PATH}" -mtime +7 -maxdepth 1 -type d \
            -not -name "*${HOSTNAME}*" -exec rm -rf {} \;
        # 每24小时执行一轮
        sleep 86400
    done
}

几点说明：

• 保留窗口差异化：GC日志的排障价值随时间衰减快，保留2天足够；消息组件的故障转移类日志排查周期更长，放宽到7天；
• 清理逻辑独立自洽：find清理放在while循环中定期执行，不依赖任何额外组件，逻辑简单、几乎零成本；
• -not -name的用意：只清理历史遗留的其他实例目录，避免误删当前实例自己的日志目录。

六、延伸：内存98%与接口耗时过长的关联

压测期间“CPU 100%＋内存98%＋接口耗时过长＋重启”这组现象，在容器化JVM服务中存在一条典型的因果链：

容器内存配比不合理 → 堆内与堆外总用量逼近limit → GC频率与停顿激增 → GC线程与业务线程抢夺CPU → 响应耗时恶化、探针超时 → 重启。

修复时除诊断参数外，还应检查两项通用配置：

1. 堆大小与容器limit的配比。JDK 10以后默认具备容器内存感知能力，JVM能正确读取cgroup限额；建议通过MaxRAMPercentage这类比例式参数设置堆上限，而不是拍一个绝对值。容器limit里要为元空间、直接内存、线程栈、代码缓存等堆外开销预留空间，经验上堆占容器内存的50%～70%起步，再结合压测数据调整。若堆贴着limit配置，几乎注定被强杀——而SIGKILL场景下JVM来不及留下任何dump，只能依靠平台事件与退出码辅助判断。
2. 探针与优雅退出的配合。健康检查的超时阈值应覆盖正常GC停顿的量级，避免一次长停顿就触发误重启；终止信号要给足优雅停机时间，让在途请求处理完毕。

七、沉淀：可复用的容器JVM稳定性检查清单

• 压测前，堆转储、GC日志、ErrorFile三项诊断参数是否全部就位；
• 所有落盘路径是否都在volumeMounts挂载目录内，容器重建后证据可留存；
• 日志滚动策略与定期清理是否形成闭环，磁盘不会被日志写爆；
• 堆内存与容器limit的配比是否为堆外预留了空间；
• 退出码与平台事件能否区分“JVM主动退出”与“被OOM强杀”；
• 健康检查超时设置是否容忍正常的GC停顿量级。

八、小结

这次排查表面上是“补几个JVM参数”，本质上是补齐容器环境下的问题定位基础设施：诊断数据先于故障存在、路径必须在持久化挂载内、日志生命周期有治理闭环、堆与limit配比合理。信创上云的迁移过程中，这类“环境变了、习惯没跟上”的问题会集中暴露，把排查过程沉淀为标准清单，才能让下一次故障发生时，证据链完整、定位路径清晰。