内存吃满先别急着加内存：用 free、top 和 ps 把内存占用讲清楚

服务器一报警说内存快满了，很多人第一反应是加内存，或者直接重启服务。重启确实能立刻把内存降下来，但问题并没有消失：过几天内存又会慢慢涨回去，而且你始终不知道到底是谁在吃内存。先花几分钟把占用讲清楚，再决定是优化、限流还是真的加内存，往往更省事。

第一步先看全局：free -h。重点看 available 这一列，而不是 free。Linux 会把空闲内存拿去做缓存（buff/cache），所以 free 看起来很小是正常的；available 才是真正还能分配给新进程的内存。如果 available 还很充裕，只是 buff/cache 占得多，那根本不用紧张，系统在压力大时会自动回收缓存。

如果 available 确实所剩无几，再用 top 按内存排序（按 M 键）看排在前面的进程。%MEM 和 RES 两列最值得看：RES 是进程实际占用的物理内存，VIRT 包含了虚拟内存和共享库，不能直接当成真实占用。一个 VIRT 很大的 Java 进程，RES 可能并没有那么夸张，别被 VIRT 吓到。

锁定可疑进程后，用 ps aux --sort=-%mem | head 得到一份更稳定的快照，方便和同事沟通或者贴到工单里。如果是某个服务在缓慢增长，可以隔一段时间各抓一次快照，对比 RES 的变化趋势：一直涨、从不回落的，大概率是内存泄漏；随业务量起伏的，则可能是正常的缓存或连接池行为。

还要留意两个容易被忽略的点。一是 Swap：如果 free -h 里 Swap 已被大量使用，说明物理内存真的不够用了，性能也会明显变差，这时才需要认真考虑扩容或迁移。二是内核的 slab 和共享内存：cat /proc/meminfo 里的 Slab、Shmem 能帮你判断是不是文件缓存或共享内存占了大头，排查方向完全不同。

最后再谈处理。确认是泄漏，就修代码或限制重启策略，而不是长期靠重启续命；确认是缓存行为，可以调小缓存上限或给关键服务设置内存上限（比如 systemd 的 MemoryMax），避免一个服务拖垮整台机器；只有在业务确实需要、且 available 长期见底时，加内存才是正确的答案。

一句话总结：先 free -h 看 available，再 top 按内存排序找进程，用 ps 抓快照做对比，最后分清泄漏、缓存还是容量不足，再动手。内存问题怕的不是占用高，而是没讲清楚就动手。