判断寻道压力大的核心是await高但iops低：await>15ms且r/s+w/s远低于设备标称值（如hdd仅几百iops），说明延迟主要来自寻道与旋转延迟，而非队列积压或带宽瓶颈。
Linux没有直接暴露“寻道时间”的指标
内核不提供单独的“寻道时间”字段，await 是唯一能间接反映它的聚合值——它包含排队时间 + 寻道时间 + 旋转延迟 + 传输时间。对机械盘来说，寻道和旋转延迟占主导（合计约 8–15ms），所以当 await 明显高于这个范围（比如持续 >20ms），且 r/s 和 w/s 不高时，大概率是随机 IO 导致磁头频繁移动、寻道成本拉高了整体延迟。
iostat -x 中哪些字段组合能提示寻道压力大
单看 await 不够，必须交叉比对：
-
await高（>15ms）但r/s和w/s很低（比如 -
%util不高（await 持续 >20ms → 设备没忙满，但每次请求都等很久，说明不是吞吐瓶颈，而是物理定位慢 -
r_await远高于w_await→ 读密集随机访问（如数据库索引扫描、小文件遍历）更易触发寻道 -
avgqu-sz很小（await 却高 → 排队不严重，问题在设备响应本身，寻道/旋转是主因
用 blktrace 确认是否真卡在寻道环节
iostat 只给平均值，blktrace 能看到每个请求的真实路径耗时：
- 运行
blktrace -d /dev/sda -o - | blkparse -i - - 关注
Q（入队）→G（获取）之间的时间差：若极短，说明块层调度快，没卡住 - 重点看
I（下发）→C（完成）之间的延迟：如果这个值普遍在 10–20ms 区间波动，且请求地址跳跃剧烈（用blkparse -f "%p %a %S %N\n"查扇区号变化），基本就是寻道在拖慢 - 配合
iotop -oP找出触发大量随机读的进程，比如mysqld或find扫描目录
查不到寻道时间，但可以估算理论下限
知道磁盘转速就能算出旋转延迟上限，再结合厂商标称寻道时间，可判断当前 await 是否已逼近物理极限：
- 7200 RPM 磁盘：平均旋转延迟 ≈
60 / 7200 / 2 * 1000= 4.17ms；企业级寻道时间通常 8–9ms → 理论最小await≈ 12–13ms - 若实测
await常达 25ms，说明实际寻道+旋转开销远超标称值，可能磁盘老化或负载模式极端随机 - 用
smartctl -a /dev/sda查Start_Stop_Count和Load_Cycle_Count，过高意味着磁头频繁启停，进一步恶化寻道效率
真正卡在寻道上时，调高队列深度或换调度器都没用——这是物理限制，唯一有效动作是减少随机 IO，比如加缓存、调大 readahead、把小文件合并或迁移到 SSD。
