NVMe 多队列与提交/完成队列调优：IOPS、延迟与队列深度可验证实践

本文聚焦 NVMe 的多队列架构（SQ/CQ）对性能的影响，通过 `fio` 的 `iodepth/numjobs` 与 `io_uring` 引擎，验证不同队列深度与并发下的 IOPS 与尾延迟，并讨论中断亲和与 CPU 绑核的实操建议。

## 前提与平台

• Linux 5.10+，启用 NVMe 多队列驱动。
• SSD：x4 通道（Gen4/Gen5），企业级或高性能消费级型号。

## 顺序与随机读写（fio 可复现）

1. 随机读（4k，调节队列深度）：

sudo fio --name=randread --filename=/dev/nvme0n1 --direct=1 \
  --ioengine=io_uring --rw=randread --bs=4k \
  --numjobs=4 --iodepth=64 --runtime=60 --time_based --group_reporting

2. 随机写（4k，谨慎在测试盘执行）：

sudo fio --name=randwrite --filename=/dev/nvme0n1 --direct=1 \
  --ioengine=io_uring --rw=randwrite --bs=4k \
  --numjobs=4 --iodepth=64 --runtime=60 --time_based --group_reporting

观察指标：`IOPS` 与 `clat (usec)`；在 `numjobs` 与 `iodepth` 提升时 IOPS 增长但尾延迟上升，需结合业务对 p95/p99 的约束进行权衡。

## 中断亲和与绑核

将 NVMe 队列中断绑定到目标 CPU，以减少跨核抖动：

cat /proc/interrupts | grep nvme
echo 2 | sudo tee /proc/irq/<NVME_IRQ>/smp_affinity_list

结合 `taskset` 将 fio 进程绑定到同一 NUMA 节点的 CPU，提高缓存命中与降低跨核迁移：

taskset -c 2-5 sudo fio ...

## io_uring 与 submit/completion 队列

`io_uring` 的 SQ/CQ 模型与 NVMe 的队列语义契合，适合高并发场景；在高负载下 `io_uring` 相比 `libaio` 往往具有更好的尾延迟表现。建议在生产前以同样的工作负载对比两者。

## 注意事项

• 写入测试会影响盘寿命与数据安全，请在测试盘或维护窗口执行。
• 调整队列深度与并发时关注温度与功耗，避免触发降速（thermal throttling）。
• 使用对齐的文件系统与分区（如 1MB 对齐）以获得稳定的随机性能。

## 结语

通过合理设置 NVMe 的队列深度、并发与中断亲和，结合 `io_uring` 的高效队列模型，可以在真实环境下提升 IOPS 并控制尾延迟，将调优结论纳入生产基线与回归流程。