排查顺序
iowait 表示 CPU 空闲且系统仍有未完成 IO 的时间比例，它升高说明「有 IO 在等」，但并不能直接证明设备是瓶颈。合理的排查顺序是：先确认 iowait 与 steal 的占比（排除虚拟化抢占造成的假象），再找出产生 IO 的进程，然后看设备侧的延迟与队列，最后评估内存回收与换页是否带来了额外的读放大。
基本信息
| 工具链 | mpstat → iotop / pidstat -d → iostat -x → PSI io |
|---|---|
| 辅助证据 | /proc/vmstat 的 pswpin/pswpout（换页）、pgscan 系列（回收） |
| 误判点 | 虚拟化 steal、swap 换入换出、内存回收导致的读放大 |
| 统计口径 | iowait 只在 CPU 空闲时累计，满负荷计算时会掩盖 IO 等待 |
| 容器视角 | 需在宿主侧确认整体压力，容器内多为宿主数据 |
典型使用场景
- 应用延迟升高伴随 wa 高，需要判断是存储问题还是内存问题
- 后台备份或同步任务影响在线业务，定位责任进程
- 容器内 IO 被邻居挤占，从宿主视角确认整体负载
- swap 导致的换入换出被误判为磁盘故障
- 虚拟化环境中识别假性 iowait，避免无效的存储调优
步骤命令
步骤命令
mpstat -P ALL 1 3 | tail -5 # 看各核 %iowait 与 %steal，先排除虚拟化因素
sudo iotop -obn 1 | tail -20 # 按 IO 排序找出最活跃的进程
pidstat -d 1 3 # 每进程的读写速率（kB_rd/s、kB_wr/s）
iostat -dx 1 3 # 设备侧延迟、队列深度与利用率
cat /proc/pressure/io # IO 停顿比例，判断对业务的实际影响
grep -E 'pswpin|pswpout' /proc/vmstat # 判断 IO 是否来自换页而非业务读写现象对照
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| wa 高、steal 接近 0 | 业务或后台任务的磁盘 IO | 用 iotop/pidstat 定位进程并考虑限速 |
| wa 高且 b 列也高 | 较多任务在等 IO | 查设备延迟与队列深度 |
| wa 高且 pswpout 增长 | 内存不足触发换出 | 转查内存、限额与回收压力 |
| st 明显大于 0 | 虚机被宿主抢占 | 与平台侧确认，而非在本机调存储 |
| wa 高但设备指标正常 | 存储链路或元数据问题 | 检查客户端、网络存储或文件系统层 |
iowait 只在 CPU 空闲时累计：系统若长期满负荷计算，等待 IO 的时间不会计入 wa，IO 压力会被掩盖。这种情况下应结合 PSI io 与设备侧指标判断。
单核 wa 打满与全核均摊的处理方式不同：前者可能只是某个进程或某条中断路径的局部问题，后者通常意味着设备或链路整体吃紧，先看每核分布再定方向。