Linux系统中分析磁盘I/O延迟应紧盯await（HDD>10ms、SSD>1ms、NVMe>1ms需介入），而非已弃用的svctm；结合r_await/w_await定位读写瓶颈，avgqu-sz>1且上升表明队列积压，%util低但await高则问题在文件系统或调度层。
Linux 系统中分析磁盘 I/O 服务的平均等待与寻道时间，关键不是直接看“寻道时间”（现代 SSD/NVMe 根本没有机械寻道），而是通过 iostat -x 1 观察真实反映延迟行为的指标组合：尤其是 await、r_await/w_await 和 avgqu-sz，再结合设备类型判断瓶颈位置。
重点看 await 而不是 svctm
svctm 字段在较新内核中已被标记为已弃用，它不准确且无法反映真实硬件响应——尤其对带控制器缓存的 SSD 或 RAID 卡，svctm 常严重低估实际耗时。真正该盯的是：
• await：I/O 请求从发出到完成的平均耗时（毫秒），含队列等待 + 实际处理时间
• r_await / w_await：分别拆解读/写路径的平均等待，能快速定位是读密集还是写密集拖慢系统
• 若 await 明显高于预期（HDD > 10ms、SATA SSD > 5ms、NVMe > 1ms），说明延迟已异常
区分“等待”和“服务”的实际含义
await 高 ≠ 磁盘硬件慢，需结合 avgqu-sz 和 %util 判断来源：
• avgqu-sz > 1 且持续上升 → 请求发得太快，内核 block 层或设备队列积压
• %util 很低但 await 很高 → 瓶颈不在磁盘本身，可能在文件系统锁（如 XFS log stall）、内核调度、或块设备驱动层排队策略
• %util 接近 100% 且 await 同步升高 → 设备确实饱和，但要注意：SSD 的 %util 99% 可能吞吐仍健康，而 HDD 达 85% 就需警惕
验证是否真有“寻道”类延迟
传统机械盘的寻道时间体现在随机小 IO 上，可通过以下方式辅助判断：
• 用 iostat -x 1 看 avgrq-sz：若长期低于 8（即
• 对比 r/s 与 rkB/s：高 IOPS（r/s > 1000）但吞吐（rkB/s）很低 → 典型随机读压力，寻道或旋转延迟成主因
• 检查 iotop -o 中进程是否频繁执行小 read() 调用（如数据库索引扫描、日志轮转）
绕过用户态工具盲区的方法
iotop、pidstat 等依赖 /proc/PID/io，对异步 I/O（io_uring、libaio）、O_DIRECT、mmap 写入统计不准。若怀疑这类场景：
• 查文件打开标志：cat /proc/PID/fdinfo/FD | grep flags，确认是否有 0100000（O_DIRECT）
• 抓底层块请求：perf record -e block:block_rq_issue -a sleep 10，再 perf script 分析来源
• 用 strace -p PID -e trace=read,write -T 看单次系统调用耗时，几百毫秒的 read/write 就说明问题在存储栈上层
