早上发现主进程没了，业务日志里没有任何退出记录，dmesg -T 里有一段 Out of memory: Killed process 指向的正是它，重启脚本也说不清原因。日志里能对上时间点，这种反而好排。
内核在内存耗尽时按 oom_score 挑进程杀，cgroup 的内存上限也走同一套逻辑，进程来不及写日志就被结束，所以要去看内核留下的记录，不是应用自己崩的。这一点先确认清楚，后面就不用反复试。
dmesg -T | grep -i -E 'out of memory|oom-kill' | tail -20 cat /sys/fs/cgroup/system.slice/app.service/memory.max cat /sys/fs/cgroup/system.slice/app.service/memory.events echo -500 | sudo tee /proc/$(pgrep -f app)/oom_score_adj
「OOM killer 定位」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。
处理上按这个顺序：在 dmesg 里找 oom 相关行确认被杀进程和时间 记下那个时刻；查对应 cgroup 的 memory.max 与 memory.events 看 oom 计数涨了多少 容器服务经常栽在这；给关键进程调低 oom_score_adj 或者放宽内存限额 两者按情况选一个。
结果对不对很好判断，连续跑两天 dmesg 没有 oom-kill 进程存活时间稳定 内存曲线也平缓了 再观察一天。