Linux OOM killer 怎样从日志确认触发对象

Linux 主机突然出现服务重启，不能只看 systemd 的“服务已退出”记录。更可靠的第一步是回到内核日志，确认是否出现 oom-kill、Out of memory 或 Kill process，再把事件里的 pid 映射到完整命令行和 cgroup。这样才能回答“到底是谁被杀、属于哪个工作负载、是整机内存不足还是局部限制超限”。下面的命令和图示是排查说明，不代表在当前机器上实际执行过的输出。

先确认日志确实来自 OOM killer

Linux 内核的 OOM 路径是在回收页面仍无法满足内存请求时判断是否需要选择进程。不同内核、发行版和日志收集器的文本略有差异，因此先按时间窗口搜索关键词，再阅读相邻行。

# 查看本次启动中的内核日志，先缩小到 OOM 相关关键词
journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process|kill process'

# 没有 systemd 日志时，从内核环形缓冲区寻找同类记录
dmesg -T | grep -Ei 'out of memory|oom-kill|killed process|kill process'

如果只能看到应用的 panic、退出码或 systemd 重启，而没有内核 OOM 关键词，不能直接把它归类为 OOM。反过来，找到 oom-kill 记录后，再向前后各看一段，通常能看到内存压力、被选 task 以及后续回收结果。

从事件行提取 pid 与进程名

常见日志会把被选 task 的名称、pid、uid、虚拟内存规模等信息放在一行或相邻几行。名称适合快速定位，pid 才适合继续查询，因为同名进程可能同时存在多个实例。

# 保留时间和原始字段，便于把事件行交给后续排查记录
journalctl -k -b --no-pager -o short-iso | grep -Ei 'killed process|kill process|oom-kill'

# 读取目标 pid 的命令行；参数以 NUL 分隔，需要转换成可读空格
tr '\0' ' ' 

这里的 PID 只是占位符，不能照抄。/proc/PID/cmdline 可以补足日志中没有显示的启动参数；如果进程已经退出，/proc 条目会消失，这时应优先保存原始内核日志，并从服务管理器或容器运行时记录补齐身份。

把 pid 映射到命令行和服务归属

在 systemd 主机上，cgroup 路径常能提示进程属于哪个 unit；在容器环境里，还可以把路径与容器运行时的限制配置对照。不要把“进程被杀”误写成“某个服务主动退出”，两者的责任边界不同。

# 按树状关系查看当前 cgroup 中的进程，帮助确认服务归属
systemd-cgls --all

# 查看某个服务的内存限制与当前状态；服务名按现场替换
systemctl show example.service -p ControlGroup -p MemoryMax -p MemoryCurrent

# 只读查看目标进程的状态摘要，确认名称和父进程线索
grep -E '^(Name|Pid|PPid|Uid):' /proc/PID/status

图中的“归属”是排查线索，不是内核给出的唯一责任判定。父进程、服务 unit、容器 cgroup 和实际启动命令可能分别来自不同层级，最好把它们记录在同一份事件时间线上。

结合前后日志判断内存压力来源

确认被杀对象之后，再判断压力范围。节点级 OOM 通常要和整机可用内存、swap、回收失败记录一起看；如果日志或运行环境显示某个 cgroup 达到限制，则应优先检查该工作负载的峰值、限制和并发。两类问题都可能出现相似的“进程突然消失”，但修复方向不同。

按证据选择修复方向

如果被杀的是批处理子进程，重点通常是限制单次工作集、降低并发或分批读取；如果是服务 cgroup 达到上限，要检查限制是否与真实峰值匹配；如果是节点级内存压力，则还要排查同一时间的其他工作负载、缓存和 swap。无论哪种情况，都先保留内核日志中的原始时间和 pid，再做调整。

OOM killer 的日志能告诉我们“内核最后选择了谁”，但不能单凭一行日志证明“谁制造了全部压力”。把事件字段、命令行、cgroup 和前后资源记录拼起来，才能从重启动作回到可执行的容量或代码改进。

常见问题

日志只有 Killed process，没有完整命令行怎么办

先保存原始内核日志，再根据 pid 查询服务管理器、容器运行时或集中式进程记录。若进程已退出，/proc/PID 消失是正常现象，不能凭空补写启动参数。

被杀进程是不是一定是内存问题的根因

不一定。它是 OOM 选择器根据当时可见的内存使用和进程属性选出的牺牲对象，真正的压力可能来自同一节点或同一 cgroup 中的多个进程。

为什么 systemd 显示服务失败但看不到 OOM

systemd 记录的是服务状态变化，OOM 证据通常在内核日志。应把两者按时间对齐；如果内核日志没有对应关键词，就继续检查退出码、应用日志和服务自身的资源限制。

排查顺序可以固定为：先找内核 OOM 证据，再锁定 pid，接着补齐命令行和 cgroup，最后结合内存压力范围决定修复动作。这样既能确认触发对象，也能避免只重启服务而遗漏真正的资源边界。