核心是盯住iostat -x的avgqu-sz和await（含r_await/w_await）：avgqu-sz反映队列深度与并发压力，await拆解读写延迟定位瓶颈类型，%wa和%util仅作辅助线索，需结合top/vmstat和进程级工具综合判断。
监控 Linux 磁盘队列深度和 I/O 等待时间，核心是盯住 iostat -x 输出中的 avgqu-sz 和 await（以及 r_await/w_await），而不是只看 %wa 或 %util。
avgqu-sz：队列深度比“忙不忙”更关键
avgqu-sz 表示设备平均有多少 I/O 请求在排队或正在处理。它直接反映上层并发压力是否超出底层承载能力：
- 值 ≈ 1：请求基本能及时被处理，队列无明显堆积
- 持续 > 1：说明请求发出速度超过设备处理能力，开始排队
- 远大于设备理论队列深度（如 NVMe 默认支持 64K 队列）：大概率是应用层并发失控，比如数据库未设连接池上限、日志轮转频繁触发小块写
- avgqu-sz 高但 %util 很低：说明请求卡在内核 block layer 或文件系统锁（如 XFS log stall），不是磁盘慢，换盘没用
await 与 r_await/w_await：区分等待来源
await 是单个 I/O 从提交到完成的平均耗时（ms），但它混合了排队时间和实际服务时间。拆开看读写延迟才能定位瓶颈类型：
- r_await 显著高于 w_await → 问题集中在读路径：可能是大量随机小读（如未命中缓存的数据库索引扫描）、文件碎片严重、或 page cache 淘汰频繁
- w_await 显著偏高 → 写路径受阻：常见于日志同步（O_SYNC）、journal 竞争（ext4）、或后端存储响应慢（如 NFS、Ceph 延迟高）
- await 高 + r_await/w_await 接近 → 整体延迟高，需查硬件响应或驱动层；若 await 高但 r_await/w_await 正常 → 问题在请求提交前，比如 vfs 层锁或调度器延迟
结合 top/vmstat 初步判断是否真有 I/O 等待
%wa 高只是线索，不是结论。要确认是否真实存在 I/O 阻塞：
- top 中 %wa 高，同时 %us 和 %sy 也高 → 更可能是进程频繁系统调用（如反复 open/close 文件），而非磁盘慢
- %wa 高但 %us/%sy 很低 → 进程确实在等 I/O，应立即查 iostat -x
- vmstat 1 中 b（阻塞进程数）持续 > 0，且 wa 同步升高 → 强信号，表明 I/O 队列已形成实质性阻塞，不是瞬时抖动
定位到高队列/高延迟后，下一步动作
别急着优化磁盘，先确认行为本质：
- 用 iotop -o 找出真正占用 I/O 的进程
- 用 pidstat -d -p PID 1 看每秒实际读写量（rkB/s/wkB/s）和合并情况（rrqm/s/wrqm/s）：r/s 高但 rrqm/s 极低 → 典型小块随机 I/O，不是吞吐问题
- 用 lsof -p PID 查打开的文件，重点关注大日志、临时文件、未关闭 fd
- 用 filefrag -v 文件 检查是否严重碎片化（尤其 ext4 上的滚动日志）
- 如果是数据库，优先查慢查询日志和执行计划，而不是调优磁盘参数
