Linux vmstat 和 iostat 怎么区分 CPU 等待还是磁盘等待

排查 Linux 变慢时，vmstat 和 iostat 不是二选一：前者回答“全机有没有任务在等”，后者回答“哪个块设备让请求变慢”。实用判断是先连续采样 vmstat，再用 iostat -x 对照设备的 await、aqu-sz 和 %util。只有当 CPU 的 wa 升高，并且同一时间某个设备的延迟或队列也升高，才适合把磁盘等待作为主要嫌疑。

先看 vmstat 的全机状态，再看 iostat 的设备状态：r 高而 wa 低，多半是 CPU 争用；wa 与设备 await、队列同时升高，才更像磁盘排队。单独一个 iowait 百分比不能证明磁盘就是瓶颈。

先用 vmstat 判断是 CPU 排队还是 I/O 等待

先执行一小段连续采样，不要只贴一行结果。vmstat 的第一行通常代表启动以来的平均状态，后续行才更适合观察当前变化：

# 每秒采样一次，共观察 5 行；-w 保留较宽的字段显示
vmstat -w 1 5

重点看 procs 和 cpu 两组。r 是可运行任务数，持续明显高于 CPU 逻辑核数时，说明任务在争用运行机会；b 是不可中断睡眠任务数，升高常提示有任务被 I/O 等待卡住。us、sy 分别表示用户态和内核态时间，wa 表示等待 I/O 的时间，id 是空闲时间。

这里要留一个边界：内核文档明确提醒，/proc/stat 的 iowait 在多核调度下并不可靠，数值还可能在特定情况下下降。因此 wa 适合做“需要继续查设备”的信号，不适合作为磁盘故障结论。

再用 iostat -x 定位具体磁盘

确认存在等待迹象后，把观察范围缩到块设备。使用 -y 跳过启动以来的历史报告，-x 展开设备字段：

# 跳过第一份历史报告，每秒输出 5 次扩展设备统计
iostat -xz -y 1 5

设备行里最有用的是 r/s、w/s、r_await、w_await、aqu-sz 和 %util。await 是请求从进入队列到完成的平均时间，包含排队和实际服务；读写压力不对称时，分别看 r_await 与 w_await。aqu-sz 可以帮助判断请求是否堆在设备前面。

%util 表示统计窗口内设备处理 I/O 请求的时间比例。对串行服务的设备，接近 100% 通常意味着饱和；但 RAID 和现代 SSD 能并行服务请求，百分比高不等于已经到达性能极限，所以还要结合 await 和业务延迟。

用同一时间窗口交叉判读

如果是第一行或单次尖峰，先别急着改调度器和 I/O 参数。保持两个命令相同的采样间隔，在业务高峰再次观察；必要时用 iostat -o JSON 留存结构化输出，减少人工抄录误差。还应确认设备映射关系，避免把 LVM、容器挂载点误当成物理盘。

常见问题

vmstat 的 wa 高，是不是磁盘一定坏了？

不是。它只说明采样窗口里出现了 I/O 等待迹象，而且内核对 iowait 的统计存在限制；必须继续用设备级延迟、队列和业务请求耗时交叉确认。

iostat 的 %util 到 100% 就一定要换 SSD 吗？

不一定。串行设备接近 100% 更值得警惕，并行设备要同时看 await、队列和实际业务延迟，不能只按一个百分比做硬件决策。

为什么两个命令的等待数值对不上？

统计范围不同：vmstat 偏全机 CPU 与任务状态，iostat 偏块设备请求；再加上采样起点、聚合层级和虚拟化环境差异，数值不必相等，时间窗口一致更重要。

事实依据：vmstat 手册、sysstat iostat 手册 和 Linux 内核 /proc 文档。