OOM 日志解读
OOM 触发时内核会打印一段结构化日志：先给出触发上下文（内存节点或 memcg 的内存概况），再列出被评估的进程及各自的 rss、oom_score 等，最后一行是 Killed process 的结论。新版内核还会附带 memcg 的用量信息。读日志时结论行之前的内容价值更高——谁在申请、谁被评估、最终牺牲了谁，连起来看才能判断是容量不足、内存泄漏还是限额设置不当。
基本信息
| 读取 | dmesg -T 中搜索 Out of memory |
|---|---|
| 重点信息 | 触发上下文、被评估进程表、最终牺牲者 |
| 新版内核 | 日志会附带 memcg 的用量 |
| 容器场景 | 宿主与容器两级日志都要看 |
| 相关文件 | /proc/<pid>/oom_score 与 oom_score_adj |
典型使用场景
- 服务突然消失且应用日志没有线索
- 排查 OOM 选择牺牲进程的依据
- 区分宿主级 OOM 与容器级 OOM
- 定位潜在的内存泄漏进程
- 复盘后把结论落到容量或限额调整上
查看完整段落
查看完整段落
dmesg -T | grep -n -B2 -A30 'Out of memory' | tail -60
dmesg -T | grep -i 'Killed process' | tail -5
journalctl -k --no-pager | grep -i -A20 'Out of memory' | tail -40
cat /sys/fs/cgroup/<组>/memory.events # 容器级 OOM 计数
cat /proc/<pid>/oom_score /proc/<pid>/oom_score_adj
free -h; grep -E 'MemAvailable|Committed_AS' /proc/meminfo日志各部分的价值
| 部分 | 内容 | 价值 |
|---|---|---|
| 触发上下文 | 节点或 memcg 的内存概况 | 判断是整机还是某个控制组先耗尽 |
| 被评估进程表 | 各进程 rss 与 oom_score | 看谁最可能被牺牲以及原因 |
| 结论行 | 被杀的进程与 PID | 只回答结果，不含原因 |
| memcg 信息 | 控制组用量（新版内核） | 容器场景下的关键线索 |
结论行之外的信息更有价值：申请者、被评估者与牺牲者要连起来读，才能定位到真正的根因。
虚拟化与容器场景要同时看宿主与容器两级日志，只查一边容易漏掉真正的限额触发点。
复盘步骤
- 把日志中的申请者、被评估者与牺牲者对应到具体服务
- 核对当时的可用内存、cgroup 限额与提交量，判断是容量问题还是限额问题
- 反复触发时优先排查内存泄漏，按增长曲线定位到进程
- 结论落到扩容、调整限额或应用修复三种动作之一