Linux vmstat 如何分辨内存抖动与磁盘等待：si、so、wa 与复测顺序

线上接口突然变慢时，先别急着把锅甩给磁盘。Linux 上跑一轮 vmstat 1 6，同一行里的 si、so 和 wa 往往能把“内存不够”和“块设备排队”分开：前者看换入换出是否持续，后者看 CPU 等待 I/O 是否同步升高。

先把“卡顿”变成一段可比较的采样

我更建议先固定采样窗口，而不是盯着一屏实时数字猜原因。下面的命令每秒采一次，共输出六行，足够观察短暂尖峰后是否回落：

vmstat 1 6

输出中的第一行通常是自系统启动以来的平均统计，不能拿来代表刚刚发生的卡顿。真正用于判断的是后面五行。把这五行连同故障时间、业务请求量一起保存下来，后面才有复测基线。

同一行里先读懂 si、so、wa

这一行最容易被误读。si 表示从 swap 换入的速率，so 表示向 swap 换出的速率；wa 表示 CPU 时间里等待 I/O 的部分。它们回答的不是同一个问题：

这组关系可以压缩成一条排查链：vmstat 先给出 si/so 与 wa 的并行信号，再用 free -h、swapon --show 或 iostat 验证是哪一类资源在排队。

si、so 持续升高时，沿着内存压力验证

如果连续多个采样行的 si 或 so 非零，先看内存和 swap 的总量、已用量，而不是立刻关闭 swap。执行：

free -h
swapon --show

free -h 只能说明当前内存账面状态，swapon --show 能补上 swap 设备和使用量。再用 ps -eo pid,comm,%mem,rss --sort=-rss | head 找出占用最大的进程，确认压力来自业务进程、缓存增长，还是短时间内的批处理。

如果 si/so 只是单行尖峰，随后回到零，可能只是一次回收或批任务触发的瞬时换页。这里别急着改 sysctl 参数，先把采样窗口拉长到业务高峰再看。

wa 持续升高时，转向块设备与进程

当 wa 连续升高而 si/so 基本为零，优先怀疑 I/O 等待，而不是内存抖动。这里把“内存回收”和“磁盘等待”当成两条不同证据链，分别用 swap 状态与设备指标确认，避免只凭卡顿体感改错方向。用下面的命令观察设备级等待：

iostat -xz 1 3

重点看设备的利用率、等待时间和队列相关指标，再结合 pidstat -d 1 5 找出正在读写的进程。若只有某个设备等待明显，下一步是查该设备上的日志轮转、批量扫描或数据库临时文件；若所有设备都正常，回到进程级锁、网络或 CPU 调度继续排除。

一套不容易走偏的复测顺序

1. 记录故障时间、业务压力和命令版本，先执行 vmstat 1 6。
2. 看后续采样行：先分开记录 si/so 与 wa，不要把它们合并成“系统很忙”。
3. 若 si/so 持续非零，补充 free -h、swapon --show 和大内存进程列表。
4. 若 wa 持续偏高，补充 iostat -xz 1 3 和 pidstat -d 1 5。
5. 只做一个针对性调整后，在近似业务压力下重新采样，比较相同字段而不是只看接口体感。

“调整”不一定是改配置，也可能是暂停批任务、错开日志压缩、限制单个进程的并发读写。先验证资源链路，再决定长期治理动作，通常比直接扩大内存或换盘更稳。

相关问答：si、so、wa 怎么判断

si 和 so 都是零，能证明没有内存问题吗？

不能。它只能说明这段采样里没有观察到 swap 换入换出。仍要结合可用内存、回收压力、进程 RSS 和业务时间窗口判断。

wa 高就一定是硬盘坏了吗？

不一定。它代表等待 I/O 的 CPU 时间，原因可能是设备队列、文件系统活动、网络块设备或某个进程集中读写，需要 iostat 和进程级数据继续确认。

为什么不只执行一次 vmstat？

单次采样无法区分持续压力和瞬时尖峰。连续窗口能看出字段是否同向、是否回落，也方便把修复前后放在同一尺度比较。

把命令和结论留在同一张清单里

排查结束时至少保留以下四项：采样窗口、si/so 读数、wa 读数、交叉验证命令及结果。这样下一次出现相似卡顿时，可以直接比较证据链，而不必从“是不是磁盘慢”重新猜起。