服务器内存爆满如何快速定位问题

学完这篇，你能在 5 分钟内判断服务器内存到底被谁吃了，并区分是「真泄漏」还是「看着像爆满」。下面按排查顺序走一遍。

第一步：确认是不是真的爆满

先别急着杀进程，很多时候内存根本没爆，只是 free 的第一列看着吓人。

free -h
cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|Buffers|Cached|Slab|SReclaimable|SUnreclaim|Shmem|SwapUsed"

判断标准只看两个：

• free -h 的 available 列，这才是应用真正还能拿到的内存；free 列几乎永远是小的，因为 Linux 会拿空闲内存做 page cache。
• SwapUsed（或 swap 行）是否在持续增长。swap 涨说明物理内存确实不够了。

注意：buff/cache 高不等于内存泄漏，它在应用申请时会被自动回收。真正危险的是 SUnreclaim（不可回收 slab）一直在涨。

第二步：按 RSS 排出吃内存的进程

这一步得到「嫌疑进程名单」。

ps -eo pid,ppid,rss,vsz,pmem,comm --sort=-rss | head -20

或者用 top：运行 top，按 M 按内存排序，按 E 把单位切成 GiB，看 RES 列。

注意：RSS 会把共享内存（如 tmpfs、共享库）重复统计到每个进程，所以所有进程 RSS 相加经常大于物理内存。别拿 RSS 总和当内存占用总和。

第三步：拆开单个进程的内存构成

锁定 PID 后，看它到底把内存花在哪。

cat /proc/<PID>/status | grep -E "VmRSS|VmSwap|VmData|VmStk|VmExe"
cat /proc/<PID>/smaps_rollup
pmap -x <PID> | sort -k3 -n | tail -20

smaps_rollup 里重点看 Rss、Shared_Clean、Private_Dirty、Swap。Private_Dirty 大，通常是堆内存；如果是 Java 进程，再补一刀：

jcmd <PID> GC.heap_info
jmap -histo:live <PID> | head -30

第四步：判断是「缓慢泄漏」还是「瞬间冲高」

pidstat -r -p <PID> 1

盯着 RSS 这一列看 30 秒。单调递增、从不回落 = 泄漏；锯齿形上下波动 = 正常 GC/缓存。

想留证据就写个采样：

while true; do date +%T; grep VmRSS /proc/<PID>/status; sleep 10; done >> /tmp/mem.log

第五步：排除三类「假凶手」

1. 内核 slab 吃光内存：slabtop -o -s c | head -20。如果 dentry / inode_cache 排在前列且很大，多半是有人在疯狂遍历文件目录。
2. tmpfs / 共享内存：df -h | grep tmpfs，重点看 /dev/shm。往 /dev/shm 写文件不落盘但占内存，最容易背锅。
3. 容器限额：容器里 free 看到的是宿主机内存，要看 cgroup。cgroup v2 执行 cat /sys/fs/cgroup/memory.max 和 memory.stat；v1 看 /sys/fs/cgroup/memory/memory.limit_in_bytes。

第六步：查是否已经被 OOM Killer 杀过

dmesg -T | grep -i -E "oom|killed process"

有输出说明已经触发过 OOM，日志里会写明被杀进程的 PID 和当时的 total-vm / rss。

小结

• 判断爆满看 available 和 SwapUsed，不看 free 列。
• 找进程用 ps --sort=-rss 或 top 按 M。
• 拆进程用 /proc/<PID>/smaps_rollup，Java 补 jcmd。
• 区分泄漏用 pidstat -r，看 RSS 是否单调增长。
• 排除 slab、tmpfs、cgroup 限额三类误判。
• 别忘了 dmesg -T | grep oom 确认是否已经被杀过。