Linux怎么查看扇区读写延迟造成的超时

iostat -x 输出中反映扇区级读写延迟的是 r_await 和 w_await 列，单位毫秒，表示内核发出请求至设备完成中断的全程耗时，不包含文件系统或 page cache 延迟。

iostat -x 输出里哪几列对应扇区级读写延迟

扇区读写延迟和应用层超时可不一样，但它可是底层超时的直接导火索。在iostat -x 1中，真正能反映扇区I/O延迟的是r_await和w_await——它们的单位是毫秒，统计的是从内核发出请求（包括扇区寻址、DMA准备）到设备返回完成中断这一整个过程所花费的时间，而不是文件系统或page cache层面的延迟。

注意：await 是读写混合平均值，掩盖了读/写路径差异；svctm 已被内核弃用（2.6.38+），数值不可信；%util 在 NVMe 上基本失效，不能用来反推扇区延迟。

• r_await > 10ms（HDD）、> 1ms（SATA SSD）、> 0.5ms（NVMe）即表明扇区读操作已异常
• w_await 持续高于读延迟，大概率是 journal 刷盘、脏页回写或 RAID 卡 write-back 缓存策略引发的扇区写阻塞
• 若 aqu-sz 长期 > 1 且 w_await 高，说明请求在块层队列堆积，还没轮到扇区执行 —— 此时不是扇区慢，是上层压太狠

ioping -C 直打设备测扇区真实响应时间

想绕过所有缓存和文件系统，只测裸设备扇区读写延迟，必须用 ioping 加 -C 参数。它发的是同步 I/O 请求，强制落盘，返回的就是控制器+介质的真实扇区往返时间。

别用默认模式：不加 -C 的 ioping /dev/sda 测的是缓存命中路径，数值虚低；dd 更不行，它只测顺序吞吐，完全不模拟随机扇区访问。

• 运行 ioping -C -c 10 /dev/nvme0n1，看输出里的 a vg 字段：NVMe 应 < 0.2ms，超 0.5ms 就要怀疑固件、PCIe 链路或电源问题
• 对 HDD 或 SATA SSD，用 ioping -C -c 20 /dev/sdb，a vg > 15ms 且 mdev > 3ms 表明存在坏道或机械臂抖动
• 如果 ioping 延迟正常，但 iostat 的 w_await 很高，问题一定出在上层：比如 ext4 的 data=ordered 模式导致大写阻塞，或 btrfs 的 CoW 触发元数据重写

查 /proc/diskstats 看扇区超时是否触发重试

内核遇到扇区读写超时（如 SCSI timeout、NVMe command timeout），会记录重试次数和失败扇区号，这些信息不出现在 iostat 里，得直接扒 /proc/diskstats。

字段顺序是固定的哦，第1列是主设备号，第2列是次设备号，第3列是设备名，第4到11列呢，则是读写统计。这里面关键要关注第10列，也就是“当前正在处理的I/O数”，还有第11列“ I/O处理总耗时，毫秒”。要是第11列的增长速度远远快于第4到7列（r/s、w/s），那就说明大量的请求卡在扇区层没返回，很可能已经超时重试啦。

• 执行 awk '{print $3,$11}' /proc/diskstats | grep sda，持续观察第11列跳变：每秒涨几百毫秒以上，基本确认有扇区级超时
• 配合 dmesg -T | grep -i "timeout|reset|offline"，找类似 end_request: I/O error, dev sda, sector 123456789 的日志，这才是扇区超时的铁证
• 某些 RAID 卡（如 MegaRAID）需额外查 /proc/megaraid/ 或用 storcli，/proc/diskstats 只反映逻辑卷视图，不暴露物理盘扇区错误

fio 测扇区长尾延迟，定位偶发超时根源

日常监控看到的 r_await 是平均值，掩盖了 p99.9 超时事件。一次 500ms 的扇区超时，在 1000 次请求里只拉高平均值 0.5ms，但足以让数据库事务超时。必须用 fio 打百分位分布。

配置要点：必须 direct=1（绕 page cache）、ioengine=libaio（用异步 I/O）、iodepth=32（模拟真实并发），否则测出来全是缓存速度。

• 命令示例：fio --name=randread --ioengine=libaio --direct=1 --gtod_reduce=1 --filename=/dev/sda --bs=4k --rw=randread --iodepth=32 --runtime=60 --time_based --group_reporting
• 重点看输出里的 clat_ns（completion latency）部分：p99.9=500000 表示 99.9% 的扇区读在 500μs 内完成，剩下 0.1% 耗时 ≥ 500μs —— 这就是你要抓的超时尾巴
• 若 p99.9 突然从 200μs 跳到 10ms，而 ioping 平均值不变，说明是驱动或固件层面的偶发 hang，不是介质老化

扇区超时不是孤立指标，它总是和调度器、队列深度、硬件健康状态耦合。盯住 r_await 和 ioping -C 的 a vg，再用 fio 扫长尾，最后用 dmesg 和 /proc/diskstats 锁定是否真发生超时 —— 这四步缺一不可。