iostat -x 1中反映寻道排队的是await、r_await、w_await和avgqu-sz四列：await表示请求全程耗时，若显著高于svctm说明排队主导；r_await/w_await失衡可定位读写密集型排队；avgqu-sz持续>1且与await同步上升则证实队列堆积。

直接用 iostat -x 1 观察关键延迟指标，而不是盯着 %util 或平均吞吐——阵列的性能故障往往藏在瞬时队列堆积和写延迟毛刺里。

盯住 r_await 和 w_await，别被 %util 带偏

存储阵列（尤其是带缓存或 RAID 控制器的）的 %util 失真更严重：它只反映控制器“有活干”的时间占比，不反映后端磁盘实际响应能力。即使 %util 才 40%，若 w_await 持续 > 20ms（SAS/SATA 阵列）或 > 5ms（全闪阵列），就说明写请求已在控制器队列里排队，不是设备慢，而是上层压得太猛或阵列缓存策略/电池状态异常。

• 重点关注 w_await 显著高于 r_await 的情况，常见于数据库日志刷盘、同步写密集型业务
• 如果 r_await 和 w_await 同步飙升，优先检查阵列是否启用了读写缓存，或是否存在全局锁（如 RAID5/6 的校验计算瓶颈）
• 对比同阵列不同 LUN 的指标：某 LUN 的 w_await 异常高而其他正常，说明问题出在该 LUN 对应的业务或卷配置上

看 avgqu-sz 和 aqu-sz 判断队列是否过载

avgqu-sz 是平均队列长度，aqu-sz 是当前活跃请求数。阵列控制器通常有固定队列深度（如 256 或 1024），查法：cat /sys/block/cciss!c0d0/queue/nr_requests（替换为你的阵列设备名，注意 ciss、hpsa、megaraid_sas 等驱动命名差异）。

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• avgqu-sz > 队列深度 × 0.7 → 队列持续饱和，控制器已无法及时消化请求
• aqu-sz 瞬时飙到接近队列上限（比如 250/256），伴随 w_await 拉长，基本可确认是控制器处理能力已达瓶颈
• 若 avgqu-sz 很低但 w_await 却高，问题可能不在队列，而在后端物理盘——比如某块盘掉速、RAID 降级或重建中

结合 -p 参数看 LUN/卷级分布，定位具体故障点

阵列暴露给系统的通常是多个逻辑设备（如 /dev/cciss/c0d0p1、/dev/sda、/dev/mapper/vg-lv）。用 iostat -x -p ALL 1 可列出所有块设备及分区，包括伪设备（如 dm-0、loop），再比对：

• 同一阵列下，某个 LUN 的 await 远高于其他 LUN → 该 LUN 对应的业务或文件系统存在异常（如 XFS 日志卡顿、ext4 barrier 等待超时）
• /dev/mapper/xxx 延迟高，但底层物理盘（如 /dev/sda）指标正常 → 问题在 LVM 层（如 thin pool 元数据锁、快照链过长）
• 所有 LUN 的 w_await 都高，且控制器设备（如 /dev/cciss/c0d0）%util 接近 100% → 故障在阵列控制器本身（固件 bug、缓存电池失效、PCIe 通道拥塞）

交叉验证：iostat + ioping + 阵列管理工具

iostat 给出的是操作系统视角的统计，需配合其他手段确认是否真实延迟：

• 用 ioping -C -c 5 /dev/your_lun 测裸设备同步延迟：若 avg > 阵列标称值（如全闪标称 0.3ms，实测 8ms），说明阵列响应层有问题
• 登录阵列 Web 管理界面或 CLI（如 hpssacli、storcli、megacli），查实时状态：是否有 Predictive Failure、Rebuild/Initialization 进行中、Cache Battery Status 是否为 OK
• 检查 dmesg | grep -i "raid\|cciss\|hpsa\|megaraid"：是否有 “timeout”、“reset”、“offline” 等错误日志