服务器内存快用完？用 free、ps 与 /proc 三步分清是缓存还是泄漏

很多人在监控里看到内存使用率超过 90% 就以为要加内存，其实先要分清：这是系统在用缓存加速，还是某个进程真的在泄漏。本文用三步现场排查法，帮你在不重启服务的前提下先定位原因。

第一步：看 free，先分清缓存和真实占用

执行：

free -h

重点看 available，而不是只看 used。Linux 会把空闲内存拿去做 page cache 和 buffers，这部分在内存紧张时可以回收。判断口诀是：available 充足、used 里缓存占比高，通常先不用慌；available 持续走低，才是真的紧张。

同时可以看：

cat /proc/meminfo | grep -E 'MemAvailable|Slab|PageTables'

Slab 异常增大往往指向内核对象或驱动问题，需要结合 dmesg 一起看。

第二步：用 ps 找真正的内存大户

ps -eo pid,comm,%mem,rss --sort=-rss | head -20

RSS 是进程实际占用的物理内存，比虚拟内存 VSZ 更有参考价值。找到大户后不要直接 kill，先确认它是不是主业务进程、有没有优雅重启或限流的办法，并用下面的命令看它随时间的变化：

ps -o pid,rss,comm -p <PID>

如果同一进程的 RSS 在业务量平稳时仍单调上涨，泄漏嫌疑就很大；如果随业务高峰涨落，多半是正常缓存或连接池行为。

第三步：到 /proc 里确认进程细节

cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap'
cat /proc/<PID>/smaps_rollup

VmSwap 大于 0 说明已经开始换出，性能会明显下降，这时扩容或限流比调优更优先。smaps_rollup 可以进一步区分匿名内存和文件映射，帮你判断是应用自身分配的内存，还是加载了过多文件、共享库。

一个可复用的处置清单

1. 先看 available，不只看使用率报警值。
2. 用 ps 按 RSS 排序，锁定前几名进程。
3. 用 /proc 确认 RSS 与 Swap 的变化趋势。
4. 能优雅重启的先做限流和灰度重启，避免直接 kill 主进程造成业务中断。
5. 反复出现泄漏时，保留当时的 ps、free 和 /proc 快照，再交给开发做堆分析。

结论

内存告警不等于内存不足。先分清缓存与泄漏，再决定是释放、限流、重启还是扩容，这样既能少花冤枉钱，也能避免把一次可恢复的缓存占用误判成线上故障。