%wa 仅表示 CPU 等待 I/O 的时间占比，需结合 iostat -x 的 await、r_await/w_await、avgqu-sz 和 %util 等指标综合判断 I/O 瓶颈根源，而非直接等同磁盘性能问题。
直接看 top 或 vmstat 输出里的 %wa（或 %iowait），这就是 CPU 在等磁盘 I/O 的时间占比，单位是百分比。 它不反映磁盘快慢，只说明“CPU 有空闲，但正在等 IO 完成”——这是起点，不是结论。
iowait 高 ≠ 磁盘慢，先确认是不是真在等磁盘
很多人一看到 %wa 超过 10% 就慌，其实它只是个信号灯，得结合其他指标交叉验证：
-
top里%wa高，但%us和%sy也高 → 很可能是进程频繁系统调用（比如反复open()/close()），不是磁盘本身慢 -
vmstat 1中b（阻塞进程数）持续 > 0 且wa同步升高 → 才算较可靠的 I/O 阻塞证据，不是瞬时抖动 -
pidstat -d -p <pid> 1</pid>显示某进程rKB/s很低，但IO%在iotop里很高 → 说明它大量时间卡在小块读写上（如数据库索引扫描），不是吞吐问题，是 IOPS 压力
用 iostat -x 看真正决定响应的字段
%wa 只告诉你“CPU 等了”，iostat -xmt 2 才告诉你“等了什么、等多久、谁在拖”：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
await：平均每次 I/O 请求延迟（ms）。HDD > 50ms、SATA SSD > 20ms、NVMe > 1ms 就该警惕 -
r_await/w_await：拆开看读/写各自延迟，能快速判断是读密集还是写密集导致卡顿 -
avgqu-sz：平均队列长度。> 1 表示请求发得太快，底层来不及处理；远大于设备队列深度（如 NVMe 默认 64K）→ 上层应用并发失控 -
%util：仅作辅助。SSD 上长期 99% 未必有问题，HDD 上 85%+ 且await同步升高才危险
别被 iotop 的 IO% 迷惑，它和 top 的 CPU 占用不冲突
iotop 显示某进程 IO% 90%，但 top 里它的 %CPU 只有 2% —— 完全正常。因为 I/O 密集型进程大部分时间处于不可中断睡眠状态（D 状态），不计入 CPU 使用率统计：
- 用
ps -o pid,comm,state -p <pid></pid>确认进程状态是否为D - 用
strace -p <pid> -e trace=read,write -T 2>&1 | head -20</pid>看单次read()/write()耗时是否异常长（比如几百毫秒） - 如果它是数据库进程，优先查慢查询日志和
EXPLAIN，而不是换硬盘
真正容易被忽略的是：await 高但 %util 低时，问题往往不在磁盘硬件，而在内核 block layer 队列或文件系统锁（比如 XFS log stall、ext4 journal 竞争）——这时候加更快的盘没用。
