磁盘队列深度过长需结合%util、r/s或w/s、await与svctm、avgqu-sz与queue_depth四指标综合判断是否真成瓶颈，不可单凭avgqu-sz高就盲目调整。
磁盘队列深度过长不是独立指标，而是I/O压力在内核块层的外在表现。它本身不能直接“调大就解决”，必须结合硬件能力、调度策略和实际负载来判断是否真成瓶颈。
先确认是不是真问题
别一看到 avgqu-sz 高就动手调。关键看三个联动指标：
- %util 持续接近 100%，且 r/s 或 w/s 远低于设备标称 IOPS（比如 NVMe 标称 80 万 IOPS，实测才 12 万）
- await 显著大于 svctm（例如 await=25ms，svctm=0.3ms），说明请求在排队而非处理慢
- avgqu-sz 持续 > 设备 queue_depth × 0.8（如 queue_depth=64，则 avgqu-sz 长期 >50 才值得关注）
如果只是 avgqu-sz 偶尔跳到 3–5，但 %util
查清楚当前队列深度上限在哪
Linux 没有统一“系统级队列深度”，要分层看：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- NVMe 设备：运行 cat /sys/block/nvme0n1/device/queue_depth，这是硬件单队列深度；多队列总数 = nr_hw_queues × queue_depth，可用 ls /sys/block/nvme0n1/device/nvme* 查子目录数量
- SATA/SAS 设备：运行 cat /sys/block/sda/device/queue_depth，部分老驱动可能不暴露，此时 cat /sys/block/sda/queue/nr_requests 是软件层主要限制
- 有 LVM/dm-crypt/mdadm：avgqu-sz 会叠加多层排队，需对比 /sys/block/dm-0/stat 和底层物理盘（如 sda）的值，才能定位是哪一层卡住
排除调度器和配置干扰
队列深度再大，被错误调度器拖住也白搭：
- 运行 cat /sys/block/sdX/queue/scheduler，NVMe 应用 noop 或 none（内核 5.0+），避免 cfq/deadline 带来额外排序开销
- 检查是否启用了同步写：ext4 默认 data=ordered，频繁 fsync 会强制刷盘，放大队列压力；高吞吐场景可评估改为 data=writeback（需权衡数据安全）
- 确认没有启用不必要的 I/O 限速（如 cgroups 的 blkio.weight 或 systemd 的 IOWeight）
谨慎调整前确认前提
临时改 queue_depth 不是万能钥匙，必须满足：
- 设备未挂载或已 umount，且无进程打开该设备（lsof /dev/sdX 确认为空）
- 驱动支持 run-time 修改（NVMe 通常支持，AHCI SATA 多数不支持，写入会报错）
- 数值为 2 的整数幂（如 32、64、128），非任意整数
- 永久生效需加内核参数（如 nvme_core.default_queue_depth=256），并 update-grub + reboot
盲目调高对 HDD 可能适得其反——默认 8–16 更稳；SSD 则优先确保调度器和队列匹配，再考虑适度提升。
