今天，我将围绕“同样是NVMe盘，为何你的写入延迟仍高”这个问题，详细拆解我在香港裸金属服务器上所经历的一次NVMe低写入抖动调优实践。通过深入配置IO队列（IO Submission/Completion Queue）和IRQ亲和性（IRQ Affinity），我成功将延迟99th从2ms降至0.4ms，尤其在高并发写入场景下写入稳定性显著增强。
一、问题背景：NVMe写入延迟高并不是“盘”的错
我们业务后台日志系统运行在一台配有Intel D7-P5520 1.6TB U.2的香港裸金属节点上。按规格来看，这块NVMe盘顺序写入应有3GB/s+的带宽，IOPS更是轻松超10万。然而在实际运行中，我们发现：
- fio测试的写入延迟均值较低（约200us），但99th延迟却高达2ms以上；
- 系统并发日志写入压力一上来，iowait抖动剧烈；
- iostat -x显示磁盘util接近满负载，但IO队列未饱和。
结合这些特征，我判断问题不是出在盘本身，而是在于内核IO调度路径和中断处理瓶颈。
二、分析定位：NVMe多队列机制与IRQ分布失衡
1. 查看NVMe设备支持的队列数
cat /sys/class/nvme/nvme0/queue_count
我们这块盘支持32对Submission/Completion Queues，这为并发IO提供了天然优势。
2. 实际启用的队列数
cat /sys/block/nvme0n1/queue/nr_requests
cat /sys/block/nvme0n1/queue/write_bw_ios
虽然支持多队列，但Linux默认的blk-mq在未做优化的情况下并不会充分利用所有CPU核进行分发。
3. 检查中断分布情况
grep nvme /proc/interrupts
输出结果显示：
122: 104032 0 0 0 0 0 0 0 IR-PCI-MSI nvme0q0
123: 328144 0 0 0 0 0 0 0 IR-PCI-MSI nvme0q1
...
中断全部集中在前几个CPU核心，造成部分核过载，其他核闲置，进而出现中断处理拥塞、IO完成延迟等问题。
三、解决方案一：绑定IRQ亲和（IRQ Affinity）到NUMA核
1. 启用irqbalance会打乱亲和性
首先关闭系统自动平衡中断的服务：
systemctl stop irqbalance
systemctl disable irqbalance
2. 为每个nvme中断绑定对应的CPU核
使用如下脚本将中断平均分布到物理核心上：
#!/bin/bash
cpu_cores=$(nproc)
idx=0
for irq in $(grep nvme /proc/interrupts | cut -d: -f1); do
core=$((idx % cpu_cores))
mask=$((1 << core))
printf "%x" $mask > /proc/irq/$irq/smp_affinity
idx=$((idx + 1))
done
如果是NUMA架构（如双路CPU机器），可以结合numactl –hardware信息只绑定在近核区域内的CPU。
四、解决方案二：优化blk-mq调度模型与IO队列参数
1. 设置IO调度器为none
NVMe设备本身硬件支持调度，Linux软件层的调度器会反而增加延迟：
echo none > /sys/block/nvme0n1/queue/scheduler
2. 增加请求队列深度
echo 1024 > /sys/block/nvme0n1/queue/nr_requests
在高并发日志写入场景中，提升请求深度能有效避免iowait抖动。
3. 查看并控制IO队列与CPU核绑定关系
cat /sys/block/nvme0n1/mq/0/cpu_list
echo 1 > /sys/block/nvme0n1/mq/0/dispatch_busy
将某个队列专门绑定到热点CPU或亲和核上可以进一步提升一致性。
五、验证与效果
在做完上述优化后，我使用如下fio脚本进行模拟：
fio --name=test --filename=/mnt/testfile --rw=write --bs=4k --iodepth=64 \
--numjobs=8 --runtime=60 --time_based --ioengine=libaio --direct=1
调整前延迟情况：
- 平均写入延迟：230us
- 99.99% 延迟：2.1ms
- iowait 偶发激增
优化后指标如下：
- 平均写入延迟：180us
- 99.99% 延迟：0.4ms
- iowait 接近零，延迟曲线更平稳
在业务层面，日志丢失率消失，订单系统的写入TPS峰值提升了约17%。
六、经验总结
- NVMe写入性能并不是“插上就满血”，合理配置IO多队列和中断亲和性至关重要。
- 默认的Linux IRQ中断绑定存在CPU倾斜，需手动介入分配。
- blk-mq模型在高IO场景下，合理调优参数（调度器、nr_requests、亲和性）可显著降低长尾延迟。
- NUMA架构机器更要注意IO队列与内存/CPU亲和性的绑定，否则出现跨节点访问会拖慢写入性能。
在香港服务器这样用于跨境高并发业务的环境中，追求不仅是性能峰值，更是稳定性和一致性。通过这次IO队列与IRQ亲和性的深入优化，我进一步认识到系统瓶颈往往隐藏在“看似无关”的中断和调度逻辑中，而不是硬件规格本身。希望本文的实践能对你解决NVMe延迟抖动问题有所帮助。
