关键看aqu-sz、r_await/w_await和吞吐模式组合：aqu-sz持续>4（SSD）或>8（NVMe）、await显著高于svctm（如45.2ms vs 0.11ms）、吞吐远低于理论带宽，三者同步异常即证实排队卡顿。
别只盯着 %util，排查存储排队过长导致的卡顿，关键看 aqu-sz（平均队列长度）、r_await/w_await 和 吞吐模式 的组合是否异常。现代 SSD/NVMe 设备即使 %util 达 100%，只要延迟低、队列短，系统依然流畅；真正卡顿往往藏在“请求堆在队列里等不到服务”的瞬间。
用对命令：必须带 -x 且动态刷新
iostat 默认输出没有队列和延迟细节，完全无法判断排队问题。必须运行：
-
iostat -x 1—— 每秒刷新一次扩展指标，观察瞬时趋势（避免看“开机以来平均”） -
iostat -x 1 /dev/nvme0n1—— 直接过滤目标设备，避开空闲盘干扰 - 加
-d可选（如iostat -dx 1），只显示磁盘行，更清爽
盯死三个排队核心指标
不是单看某个数，而是看它们是否“不匹配”：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
aqu-sz（平均队列长度）：持续 >4（SATA SSD）或 >8（NVMe）就需警惕；若 > 队列深度 × 0.7（查
cat /sys/block/nvme0n1/queue/nr_requests），说明队列已严重积压 - w_await 或 r_await > 20ms（SSD）或 >50ms（HDD），且明显高于 svctm（通常接近 0.x ms）→ 请求不是被设备拖慢，而是卡在队列里等
- rkB/s + wkB/s 远低于理论带宽（如 NVMe 标称 3GB/s，实际才 200MB/s），但 aqu-sz 和 await 却很高 → 排队瓶颈不在硬件，而在上层（文件系统、日志刷盘、锁竞争）
区分是真排队，还是假拥堵
高 aqu-sz 不一定代表坏，得结合操作类型判断：
- 大量小文件同步写（如
fsync()频繁调用）、XFS 日志提交卡顿、ext4 开启 barrier → 容易触发写队列堆积，w_await 高但 wkB/s 很低 - 随机读密集型负载（如数据库索引扫描），r/s 高但 rkB/s 低 → 单次请求小，队列容易填满，r_await 上升快
- 如果 aqu-sz 高但 await 稳定在 1–2ms（SSD），wkB/s 接近标称值 → 是健康高并发，不是卡顿
往下定位“谁在塞队列”
iostat 告诉你“队列满了”，但不告诉你“谁在塞”。下一步必须关联进程：
-
iotop -oP—— 只显示正在做 IO 的进程，按实际字节速率排序，一眼揪出高频小写或阻塞式同步写的元凶 -
pidstat -d 1—— 查每个进程的 r/s、w/s、rkB/s、wkB/s，对比历史基线，发现异常突增 -
lsof -p PID—— 对可疑进程，看它打开的是哪个文件、挂载在哪块设备上（比如写的是 /var/log 下的小日志文件，对应 /dev/sda1）
