Linux 内存排查实战：从 OOM Killer 日志到 RSS 虚高的定位方法

在生产环境里，Linux 服务器的内存问题往往以两种面貌出现：一种是进程被 OOM Killer 直接杀掉，服务瞬间不可用；另一种更隐蔽——监控显示内存持续上涨，但登录机器一看每个进程的 RSS 都不算大，free 的 available 却所剩无几。这两种现象的排查路径完全不同，本文结合真实案例梳理定位方法。

一、先用 dmesg 确认是不是 OOM Killerdmesg -T | grep -i -E 'out of memory|killed process'

这条命令几乎能一秒钟给出结论。典型输出会包含 oom-kill:constraint=CONSTRAINT_NONE,nodemask 以及被选中进程的 total-vm、anon-rss、file-rss 和 oom_score_adj。关键要看 oom_score_adj：如果被杀的是业务进程而它并非内存大户，往往说明 systemd 服务或容器里没有正确设置 OOMScoreAdjust，导致内核挑错了牺牲者。

确认是 OOM 之后，不要急着加内存。先回答两个问题：被杀进程的 anon-rss 真实峰值是多少，以及系统在那一刻 available 还剩多少。前者用 /proc/<pid>/status 的 VmHWM 记录，即使进程已死，容器场景下也能从 cgroup v2 的 memory.peak 里读到历史峰值。

二、RSS 不高但内存吃紧：先看 Slab 和可回收内存

第二种现象通常不是进程泄漏。用 free -h 看 available 偏低时，先执行 cat /proc/meminfo | grep -E 'Slab|SReclaimable|SUnreclaim|PageTables|KernelStack'。如果 SUnreclaim 达到几个 GB，问题在 dentry/inode 缓存或内核对象泄漏，可用 slabtop -s c 定位具体缓存类型。若是 SReclaimable 偏高，属于正常缓存，不该算作内存不足，此时调大 vm.vfs_cache_pressure 即可加快回收。

另一个高频原因是 PageTables 异常膨胀。当业务使用大量 mmap 或频繁 fork 时，页表本身可能占用数 GB。对比 /proc/<pid>/status 中 VmPTE 与 VmRSS 的比例，如果 VmPTE 超过 VmRSS 的 30%，说明存在大量的稀疏映射，需要检查是否误用了 MAP_NORESERVE 或大页配置不当。

三、定位到具体进程：从 smaps 看内存去向

确认是进程级问题后，推荐用 awk 聚合 /proc/<pid>/smaps_rollup 的数据，比逐行读 smaps 快得多且不影响业务。重点看 Anonymous、Shared_Clean、Pss 三个指标。Pss 尤其重要：多进程共享同一块内存时，RSS 会把每个进程都算一份，造成严重虚高，而 Pss 按共享比例分摊，才是真实占用。监控如果只读 RSS，就会误判内存泄漏。

实操中我遇到过 Java 应用 RSS 显示 12GB、实际 Pss 只有 4GB 的情况，原因是有 8GB 的共享映射被 20 多个 worker 重复计入。把监控指标从 RSS 换成 Pss 之后，告警噪音下降了九成。

四、几条预防建议

1. 给关键业务进程显式设置 oom_score_adj=-500 到 -900，避免被内核优先选中；2. 容器统一使用 cgroup v2，并通过 memory.high 做软限制，让内存在触顶前就开始回收而不是直接 OOM；3. 监控侧同时采集 RSS 与 Pss，两者比值超过 2 时提示共享内存异常；4. 对 vm.overcommit_memory 保持默认的 0，不要为了避免报错改成 1，那会掩盖真实的内存压力并引发更晚更惨烈的故障。

内存排查的核心不是找命令，而是先分清谁杀了进程和内存去哪了这两类问题。前者看 dmesg，后者看 meminfo、slabtop 和 smaps，再配合 Pss 口径校正，绝大多数线上内存疑云都能在半小时内给出结论。