必须用vmstat观察si和so两列才能发现Swap抖动，执行vmstat 1 10每秒采样、共10次，连续≥3次si>0或so>100 KB/s即表明频繁换入换出，si/so同步升高更危险。
Swap 换入换出频率不能靠 free -h 或 swapon --show 看出来，必须用 vmstat 观察 si 和 so 两列——它们是唯一实时反映“抖动”的指标。
怎么用 vmstat 抓住 Swap 抖动瞬间
默认 vmstat 5 秒刷新一次，容易漏掉短时尖峰；内存压力常以秒级脉冲出现，必须提高采样密度。
- 执行
vmstat 1 10：每秒刷新，共 10 次，足够捕获典型抖动周期 - 紧盯
si（swap-in，单位 KB/s）和so（swap-out，单位 KB/s）两列 - 只要连续 ≥3 次出现
si > 0或so > 0，尤其数值 >100，就说明内核正在频繁搬运页面 - 若
si和so同时升高，比单向搬运更危险——进程在反复换入又立刻换出，是内存严重不足的强信号
为什么 si/so 非零比 swap used 高更值得警惕
swpd（vmstat 输出中 swap 使用总量）只告诉你“静态占了多少”，而 si/so 揭示的是“此刻是否在狂搬”。后者直接关联 I/O 延迟和响应卡顿。
- swap used 1.8G / 2.0G 但
si=so=0 → 可能只是历史残留，页未回收，无实际压力 - swap used 仅 300M 但
so持续在 200–500 KB/s 波动 → 内核正主动换出冷页，配合MemAvailable偏低才构成真实风险 - 如果
bi（块设备读）和bo（块设备写）同步飙升，基本可确认 swap 搬运正在抢占磁盘带宽
如何交叉验证 si/so 异常是否真由内存压力引起
vmstat 告诉你“有抖动”，但不告诉你“谁干的”。必须结合其他指标排除干扰、定位根源。
- 先看
free -h第二行的available：若MemAvailablesi/so持续非零，基本可锁定为内存不足 - 检查
/proc/sys/vm/swappiness：值 >60 会显著放大换出倾向；设为 1–10 可抑制非必要so，但无法阻止真正缺内存时的换出 - 运行
cat /proc/meminfo | grep -E "Inactive\(anon\)|SwapTotal"：若Inactive(anon)接近SwapTotal，说明大量匿名页已被标记为可换出，so升高只是时间问题 - 注意 SSD vs HDD：HDD 上
so值可能不大（如 50 KB/s），但wa（iowait）会明显升高，这是延迟敏感型抖动的特征
哪些场景下 si/so 上升 ≠ 内存真不够
不是所有 swap 搬运都代表系统病了。Linux 的内存管理策略会让它“主动换出”，即使物理内存还有空闲。
- Java 进程使用
DirectByteBuffer：这部分堆外内存不计入RSS，但会进 swap，表现为so上升而top里看不到对应进程内存异常 - 内核认为某些页“冷”且 swap 在 SSD 上：此时换出是优化行为，目的是腾出空间给 page cache，
si/so轻微波动属正常 - 刚启动大进程后退出：swap used 仍高，但
si/so为 0，说明没有活跃搬运，只是页尚未被回收
真正难判断的点在于：抖动是瞬时负载尖峰引发的短暂现象，还是持续性内存泄漏的早期征兆。这时候不能只盯一次 vmstat，得配合 smem -s swap -r 或 ps aux --sort=-%mem 持续观察进程级 swap 波动，再回溯日志看是否伴随服务延迟上升。
