内存一直涨不回落：泄漏还是缓存

看到内存占用一路上涨，先别急着重启，很多"泄漏"其实是缓存在替你干活，重启反而把干活的人赶跑了。 怎么区分缓存和泄漏 free -h 的输出里，available 才是"还能给新程序用多少"，别看 free 那一列。Linux 会把空闲内存拿去做页缓存（buff/cache），应用要用时随时归还，所以 used 和 cache 涨都正常。判断标准：available 长期充足、buff/cache 占大头，是缓存，不用管；available 一路下跌、buff/cache 基本不动，才是真泄漏。排查期别用 drop_caches 手动清缓存，内存瞬间"释放"只会掩盖问题。另一个易混项是内核的 slab：cat /proc/meminfo 里 SReclaimable 属于可回收的内核缓存，slabtop 能看明细，它同样会涨、同样不算泄漏。 泄漏在哪个进程 top 按 M 排序，或执行 ps aux --sort=-rss | head -10，看 RSS（常驻内存集）最大的几个进程。观察要有节奏：watch -n 60 'free -m; ps aux --sort=-rss | head -5' 挂在屏幕上，每分钟记一次，一晚上下来谁在涨一目了然；有监控平台的直接看内存趋势加进程维度的曲线。判断关键是对比：数据库、文件服务这类进程 RSS 会涨也会随缓存淘汰回落，泄漏型进程只涨不降，曲线形态不一样。验证缓存在干活有个土办法：同一批文件连读两遍，第二遍明显变快，说明缓存正常工作，它涨得有理。怀疑某个进程泄漏，先看 /proc/PID/status 里的 VmRSS 每分钟记一次，足够定性。 重启验证法 拿不准时，重启嫌疑进程再观察：内存立刻回落且此后平稳，是配置不当或版本问题；几天后同样姿势再涨，泄漏实锤，去查该版本的已知问题、连接池上限和缓存淘汰策略。重启是诊断手段，不是治疗方案，别让它变成每周例行公事。 预防的硬手段 给常驻服务设内存上限：数据库的 buffer pool、应用的缓存条数上限、JVM 堆上限，让泄漏没有发挥空间。用 systemd 管理的服务可以写 MemoryMax=4G，超限先限制住，不拖垮整机——限额要留足余量，再配一条"available 低于一成半告警"兜底。容器化部署的把内存限制写进编排文件，道理与 systemd 单元相同。