linux中查看块设备队列深度需分设备类型：scsi/sas设备读取/sys/block//device/queue_depth；nvme设备则查/sys/block/nvme0n1/device/queue_count及各队列depth，或用nvme get-ns-id；ide等非scsi设备该路径不存在。
查看块设备当前队列深度（queue_depth）
Linux内核为每个SCSI/SAS/NVMe块设备维护一个硬件队列深度，它直接限制该设备同一时刻能并行处理的I/O请求数。这个值不是由系统管理员随意设定的，而是由驱动从设备固件中读取或根据协议协商得出，但可被手动调整（需谨慎）。最直接的查看方式是读取/sys/block/<device>/device/queue_depth</device>：
- 例如查
sda：运行cat /sys/block/sda/device/queue_depth；若报错“No such file or directory”，说明该设备不走SCSI子系统（如部分NVMe或IDE模拟设备） - 对NVMe设备，应查
/sys/block/nvme0n1/device/queue_count和每个队列的深度（/sys/block/nvme0n1/device/queue/0/depth），但更常用的是nvme get-ns-id /dev/nvme0n1中的nn（命名空间数）和控制器能力 - 注意：
queue_depth是单个LUN的深度，而多路径（multipath）设备会聚合多个路径，实际有效并发受 multipathd 配置和底层路径 queue_depth 共同影响
修改 queue_depth 的风险与正确时机
盲目增大 queue_depth 不仅不能提升吞吐，反而可能引发设备固件 hang、超时重试风暴甚至数据损坏。只有在确认以下条件同时满足时才考虑调优：
- 设备本身支持更高深度（查厂商文档或用
sg_inq /dev/sda看 VPD页，重点看 “Maximum Queue Depth” 字段） - I/O负载长期处于高并发、低延迟敏感场景（如OLTP数据库、高频小IO随机写），且
iostat -x 1显示avgqu-sz持续接近或等于当前queue_depth，同时%util接近100% 且r_await/w_await明显升高 - 驱动已启用 tag-based I/O（如
scsi_mod.use_blk_mq=1）且内核 ≥ 4.12；老内核用 legacy queue 机制，改 depth 效果有限 - 修改必须在设备空闲时进行：先
echo 0 > /sys/block/sda/device/delete（移除设备），再 echo 新值到queue_depth，最后 rescan；NVMe 通常不支持运行时修改 depth
真正影响磁盘IO吞吐的其实是 blk-mq 队列数与调度器协同
现代Linux（≥4.0）默认启用 blk-mq（multi-queue block layer），此时单个 queue_depth 只是每个硬件队列的容量，真正决定并发能力的是「硬件队列总数 × 单队列深度」。例如 NVMe 控制器常有 64 个队列，每队列默认深度 1024，理论最大并发达 65536 —— 但应用层是否真能打满，取决于：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
io scheduler是否禁用（SSD/NVMe 应设为none，避免额外延迟；机械盘才用mq-deadline或bfq）：检查cat /sys/block/nvme0n1/queue/scheduler，写none生效 - 应用是否使用异步I/O（
libaio+io_submit）或 io_uring；同步write()无法利用多队列并行性 - 文件系统挂载参数：ext4/xfs 需加
noatime,nodiratime,commit=30减少元数据刷盘争抢；XFS 推荐logbsize=256k提升日志吞吐
验证优化是否生效的关键指标
改完别急着看带宽数字，先确认底层机制是否按预期工作：
- 用
cat /sys/block/sda/device/queue_depth和ls /sys/block/sda/device/queue/（看是否有多个 queue/ 子目录）确认 mq 已启用且 depth 已更新 - 运行
iostat -x 1观察：优化后avgqu-sz应稳定在新 depth 的 60–80%，r/s+w/s上升，r_await/w_await下降，且%util不再长期 100% - 用
perf record -e block:block_rq_issue,block:block_rq_complete -a sleep 10抓取块层事件，再perf script | grep sda看 request issue 到 complete 的延迟分布，确认无大量 >100ms 的离群点
队列深度只是I/O栈中一环，脱离设备能力、驱动模型和应用I/O模式单独调它，大概率白忙活。尤其在虚拟化环境里，宿主机的 queue_depth 设置可能被QEMU透传逻辑覆盖，这时得去查 virsh dumpxml 里的 <driver name="qemu" queues="N"></driver> 配置。
