Linux OOM日志是内核内存危机时的决策快照，需提取被杀进程身份、内存压力现场、触发层级归属三类硬信息；关键字段包括Killed process PID(name)、total-vm/anonymous-rss/file-rss数值、同时间Mem-Info快照，并结合cgroup路径判断越界主体。
Linux OOM 日志不是“谁占内存最多就杀谁”的简单记录，而是一份内核在内存危机时刻生成的决策快照。看懂它，关键不在找关键词，而在提取三类硬信息：被杀进程身份、内存压力现场、触发层级归属。
抓准日志里的三个核心字段
别只搜 “Out of memory”。真正有效的日志行必须同时包含：
- Killed process XXX (name)：明确写出 PID 和进程名（如 Killed process 2841 (java)），这是唯一确认“谁被终结”的依据
- total-vm / anon-rss / file-rss 数值：total-vm 是进程申请的虚拟内存总量，anon-rss 是它实际占用的物理内存（堆/栈等），file-rss 是文件映射占用的物理页；三者差值大，说明存在大量已分配但未使用的虚拟地址空间
- 同一时间点的 Mem-Info 快照：出现在 dmesg -T 或 /var/log/messages 中，含 Active(anon)、Inactive(file)、SwapCached、PageTables 等字段，能判断压力来自应用堆、页表膨胀，还是缓存无法及时回收
区分是整机告急，还是某个容器/服务越界
日志里藏着“责任主体”线索：
- 若出现 cgroup: /system.slice/docker-abc123.scope 或 /kubepods/burstable/podxxx 这类路径，说明是 cgroup 级别超限——进程没超宿主机总内存，但撞上了自己被分配的限额（比如 Java 设了 -Xmx4g，cgroup 却只给了 3g）
- 若无 cgroup 路径，且 free -h 的 available 持续趋近于 0、vmstat 1 中 si/so 频繁非零，大概率是全局内存不足，swap 正被高频使用
- 若日志里只有 Out of memory: Kill process 却没列 PID，说明内核连日志缓冲区都快撑爆了，需立刻检查 vm.panic_on_oom 是否为 1（设为 1 会直接重启）
验证是否真“内存不够”，而非误判
Linux 的 OOM 触发不等于物理内存耗尽，而是内核判定“安全水位跌破 + 无法快速回收连续页”。验证要点：
- 查 cat /proc/meminfo | grep -E "(Committed_AS|CommitLimit)"：若 Committed_AS > CommitLimit，说明 overcommit 已超限，属于内核主动拒绝分配，不是物理内存真没了
- 查 vm.min_free_kbytes 设置：64 位系统建议设为总内存的 0.5%~1%（如 32G 内存可设 524288，即 512MB）；设得过高（如 1GB+）会导致过早触发 OOM
- 用 slabtop -o 看内核 slab 是否异常（如 dentry、ext4_inode_cache 持续增长），这类泄漏不会体现在进程 RSS 中，但会吃掉大量不可回收内存
定位后该怎么做
拿到日志结论后，动作要分层：
- 对关键进程（如数据库、SSH），立即执行 echo -1000 > /proc/PID/oom_score_adj，给它加免死金牌
- 对 cgroup 场景，调高对应 memory.limit_in_bytes，或同步调整应用内存参数（如 Java 的 -Xmx），确保两者匹配
- 云主机务必配 swap：哪怕只是 2–4GB，也能极大延缓 OOM 触发时机，避免因瞬时 spike 被误杀
- 长期治理，开启 earlyoom 替代默认 OOM Killer，它响应更快、策略更可控，且支持自定义优先级规则
