%wa高不等于磁盘瓶颈，需结合iostat -x的await、r_await/w_await和avgqu-sz判断：await升高但%util低时，问题常在文件系统锁或内核队列，而非磁盘本身。
iostat -x 1 是最直接有效的手段，但单看 %wa 或 %util 容易误判；真正关键的是 await、avgqu-sz 和 r_await/w_await 的组合。
怎么看 top 或 vmstat 里的 %wa 是否真有问题
top 输出中 CPU 行的 %wa 高，只说明 CPU 在等 I/O，不等于磁盘慢。常见误导场景：
-
%wa高但%us和%sy也高 → 可能是进程在做大量系统调用（如频繁open/close），未必是磁盘瓶颈 -
%wa高而%us/%sy很低 → 更可信的 I/O 等待信号，需继续查iostat -
vmstat 1中b（阻塞进程数）持续 > 0 且wa同步升高 → 强烈提示 I/O 阻塞，不是瞬时抖动
iostat -x 输出里哪些字段必须盯住
运行 iostat -xmt 2（扩展统计 + MB/s 单位 + 时间戳 + 2秒刷新），重点关注这几列：
-
await：平均 I/O 延迟（ms）。HDD > 15ms、SATA SSD > 5ms、NVMe > 0.5ms 就该警惕 -
r_await/w_await：分别看读/写延迟，能区分是读密集还是写密集拖慢 -
avgqu-sz：平均队列长度。> 1 表示请求发得太快，底层来不及处理；远大于设备队列深度（如 NVMe 默认 64K）说明上层应用并发失控 -
%util：仅作辅助参考。SSD/NVMe 上长期 95%+ 但await
为什么 iotop 显示某进程 IO% 很高，但 top 里 CPU 占用却很低
完全正常。I/O 密集型进程大部分时间处于不可中断睡眠状态（D 状态），不计入 top 的 CPU 使用率，但会被 iotop 捕获。验证方法：
- 用
ps -o pid,comm,state -p <pid></pid>确认进程状态是否为D - 用
pidstat -d -p <pid> 1</pid>查看每秒实际读写量（rkB/s/wkB/s）和合并情况（rrqm/s/wrqm/s） - 若
r/s高但rrqm/s极低 → 大量小块随机读（如数据库索引扫描），不是吞吐问题而是 IOPS 压力
排查到高 IO 进程后，下一步该查什么
别急着 kill，先确认行为本质：
- 用
lsof -p <pid></pid>看它打开了哪些文件；重点检查大日志、临时表、未关闭的 fd - 用
filefrag -v <file></file>查文件是否严重碎片化（尤其 ext4 上的大型日志） - 用
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 竞争），这时候换更快的盘没用，得看 iostat -x 的 avgqu-sz 和调度器配置。
