vmstat不能直接发现内存泄漏，但能通过free持续下降、swpd上升、si/so持续非零等异常趋势暴露内存泄漏迹象，需结合free -h的available值和ps命令交叉验证定位问题进程。
vmstat 本身不能直接“发现”内存泄漏，但它能清晰暴露系统因内存不足而产生的异常行为模式，这些模式是内存泄漏正在发生或即将引发严重问题的关键信号。排查重点不是看某个数字“高不高”，而是观察趋势是否持续恶化、多个指标是否联动异常。
看 vmstat 1 输出里的关键字段
运行 vmstat 1（每秒刷新一次），重点关注以下几列：
-
free：空闲物理内存（KB）。持续下降、长期接近零，说明内存被不断占用且未释放。 -
buff和cache：缓冲区和页缓存。它们会随文件读写自然波动，但若free持续减少而buff/cache不同步增长（甚至下降），说明不是缓存占用了内存，而是进程在吃掉真实可用内存。 -
swpd：已使用的交换空间（KB）。从 0 开始缓慢上升，尤其在业务空闲时仍在增长，是内存泄漏的强提示——内核被迫把部分内存换出到磁盘。 -
si（swap in）和so（swap out）：单位时间内换入/换出的内存页数（KB/s）。只要si或so持续非零（比如 > 10 KB/s）且稳定存在，就表明系统已进入内存紧张状态，正在频繁换页。这不是“偶尔抖动”，而是持续压力。 -
r（run queue）：等待 CPU 的进程数。如果r长期大于 CPU 核心数，同时free和available（需结合free -h看）也在降，说明内存瓶颈已拖慢整体调度。
把 vmstat 和其他命令联动验证
单靠 vmstat 只能看到“系统很累”，要确认是泄漏，必须交叉验证：
- 同时运行
free -h，紧盯available值：如果vmstat的free在掉，free -h的available也在同步、缓慢、不可逆地下滑（尤其在无负载时），基本可锁定泄漏。 - 如果
swpd上升 +si/so持续活动 +dmesg | grep -i "killed process"出现 OOM 记录，说明泄漏已导致系统自保机制启动。
实用监控建议
- 快速观察：
vmstat 1 30（采集30秒数据，避免干扰判断） - 长期记录：
vmstat 5 > vmstat.log &（每5秒记一次，后台运行，便于事后分析趋势） - 结合进程定位：一旦确认系统级内存压力，立刻用
ps -eo pid,cmd,rss --sort=-rss | head -10找出 RSS 最大的几个进程，再用watch -n 5 "ps -p <pid> -o pid,rss,vsz,%mem"</pid>观察其内存是否单向增长。
它不告诉你哪行代码漏了，但能明确告诉你：“别猜了，内存正在被悄悄吃掉，而且停不下来。”
