Docker容器运行时故障排除OOMKilled退出码137
场景
某生产环境中运行Java应用的Docker容器频繁重启，状态显示Exited (137)。应用日志无异常，但容器退出码为137。
症状
docker ps -a显示容器状态为Exited (137)docker inspect <container>输出中State.ExitCode为137，且State.OOMKilled为true- 主机
dmesg可能包含Out of memory: Kill process或oom-killer信息 - 容器内存使用接近或超过限制
诊断步骤
- 检查退出码：
docker inspect <container> --format='{{.State.ExitCode}}' - 查看OOM状态：
docker inspect <container> --format='{{.State.OOMKilled}}' - 检查内存使用：
docker stats <container>或直接读取cgroup文件：cat /sys/fs/cgroup/memory/docker/<container-id>/memory.usage_in_bytes - 查看系统日志：
dmesg | grep -i oom - 分析应用内存配置：检查JVM参数如
-Xmx、-Xms
常用命令
- 查看容器详细信息：
docker inspect <container> - 查看日志：
docker logs <container> - 实时监控：
docker stats --no-stream - 调整内存限制后重启：
docker update --memory 512m --memory-swap 512m <container>并docker restart <container>
风险控制
- 设置合理资源限制：使用
--memory和--memory-swap参数，确保memory-swap等于memory以禁用swap - 预留内存：使用
--memory-reservation设置软限制 - 监控告警：配合Prometheus等工具监控容器内存使用率，设置告警阈值
- 生产环境：使用Kubernetes的ResourceQuota和LimitRange
回滚方案
- 如果调整参数后问题依旧，回滚至之前的镜像版本：
docker rollback <container>或重新部署旧镜像 - 恢复原始资源限制：
docker update --memory <original> --memory-swap <original> <container>
验证修复
- 确认容器稳定运行：
docker ps显示Up状态 - 检查内存使用：
docker stats <container>确认使用量低于限制 - 无新OOM日志：
dmesg无相关输出
何时提交OpsGlobal工单
- 持续OOM且资源限制已合理调整
- 主机层面内存耗尽（非单一容器问题）
- 需要优化JVM或应用内存配置，缺乏内部经验
- 容器运行时出现内核级错误（如segfault、超时）
适用场景
适合正在处理 DevOps、Docker, 容器运行时, 故障排除, OOMKilled 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
本文深入探讨Docker容器运行时常见故障，特别是OOMKilled问题，提供从症状、诊断到修复的完整流程，并指导何时寻求OpsGlobal专业支持。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。