Linux SRE 运维手册：生产环境内存溢出（OOM）故障排查

场景

某生产 Linux 服务器上的关键应用程序频繁被 Out-Of-Memory (OOM) Killer 终止，导致服务中断。

症状

• 应用崩溃，客户端请求失败
• 系统日志显示 OOM Killer 信息：dmesg | grep -i oom 输出中包含 Killed process
• 内存使用率随时间逐渐上升，free -m 显示可用内存持续下降
• top 或 htop 中个别进程占用大量内存

诊断

1. 确认 OOM Killer 事件：dmesg -T | grep -i 'oom-killer' 或 journalctl -k | grep -i oom
2. 查看当前内存使用：free -h、cat /proc/meminfo、vmstat -s
3. 识别内存消耗大户：ps aux --sort=-%mem | head 或 top -o %MEM
4. 深入分析进程内存映射：pmap -x <PID> | sort -n -k2 | tail 或 smem -t -p -k | sort -n
5. 检查 cgroup 内存限制（如使用容器）：cat /sys/fs/cgroup/memory/memory.usage_in_bytes
6. 查看系统内存配置：sysctl vm.overcommit_memory、sysctl vm.panic_on_oom

命令

# 查看最近 OOM 事件
dmesg -T | grep -i 'oom-killer'

# 查看内存总量和已用量
free -h

# 按内存占用排序进程
ps aux --sort=-%mem | head -20

# 查看进程详细内存映射（以 PID 12345 为例）
pmap -x 12345 | sort -n -k2 | tail -10

# 使用 smem 查看 USS/PSS
smem -t -p -k -c "pid username command pss uss"

# 调整 OOM 行为（临时）
echo 2 > /proc/sys/vm/overcommit_memory  # 禁止过量分配
echo 0 > /proc/sys/vm/panic_on_oom      # OOM 时触发内核 panic？通常设为 0

# 重启问题服务（如 nginx）
systemctl restart nginx

风险控制

• 在终止进程前，确认该进程是否可以安全杀死（例如使用 systemctl status 查看是否为核心服务）。
• 使用 renice +10 -p <PID> 降低问题进程优先级，避免立即触发 OOM。
• 修改 vm.overcommit_memory=2 可减少过量分配，但可能导致内存分配失败，需在低峰期操作。
• 如果问题进程是合法业务进程，考虑增加物理内存或设置 cgroup 内存限制。

回滚

• 若误杀进程，使用对应命令重启服务：systemctl start <service> 或手动执行启动脚本。
• 若修改了 sysctl 参数且导致新问题，恢复默认值： bash sysctl -w vm.overcommit_memory=0 sysctl -w vm.panic_on_oom=0 或从备份 /etc/sysctl.conf 恢复。

验证

• 监控 /proc/meminfo 中 MemAvailable 是否稳定。
• 检查 dmesg 无新的 OOM Killer 消息。
• 应用健康检查端点返回 200。
• 负载测试模拟正常流量，确认无内存泄漏。

何时提交 OpsGlobal 工单

• 经过上述排查仍无法定位根本原因。
• 需要内核参数调优涉及生产环境全局变更。
• 疑似内核 bug 或需要配置专业的监控告警（如 Prometheus + Grafana）。
• 需要 OpsGlobal 工程师协助编写自动化恢复脚本或定制 runbook。