HDUO Lab

深入 NVMe IO 延迟雪崩排查：默认调度器误用引发的 blk-mq 锁争用与软中断打满实战

作者：

ningniu

在

某次核心分布式 KV 存储集群进行底层硬件换代，全面升级至 Gen4 NVMe SSD。本以为硬件红利能让 IO 性能起飞，结果压测一上，QPS 刚到 8 万，99线（p99 latency）就开始周期性从 2ms 剧烈抖动到 300ms 以上。Load Average 狂飙至机器核数的两倍，大量写入线程陷入 D 状态（Uninterruptible Sleep）。 一句话交代结论：这是一起典型的“旧时代运维习惯毒害新硬件”的事故。系统镜像中遗留的 udev 规则将 NVMe 设备的 IO 调度器默认设置成了 mq-deadline。在极高并发下，这个多余的软件调度层在内核 blk-mq（块设备多队列）中引发了极其严重的自旋锁争用（Spinlock Contention），直接打满 ksoftirqd 软中断，导致 IO 请求在 OS 提交队列里排队，根本没送进物理磁盘。 解决方式极其简单：echo none > /sys/block/nvme0n1/queue/scheduler。

案发现场与指标拆解

排查过程中，第一直觉是新批次的 NVMe 盘存在固件缺陷或发生了 GC（垃圾回收）拥塞。习惯性敲下 iostat -xz 1，看到的数据却极为诡异：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme0n1           0.00    12.00  340.00 45000.00  5440.00 720000.00    32.00   145.50  180.20    1.50  182.10   0.01  15.20%

注意看这几个核心指标的矛盾点：

  1. %util 只有 15.20%：说明磁盘底层的物理带宽和 IOPS 根本没跑满，处于极度饥饿状态。

  2. svctm（服务时间）仅为 0.01ms：说明盘的物理响应极快，一旦请求交到硬件手里，瞬间就能处理完。

  3. w_await 高达 182.10ms，avgqu-sz（平均队列长度）达到 145.5：请求虽然处理得快，但排队时间长得离谱。

这说明一个铁打的事实：IO 根本没有卡在硬件设备上，而是卡在了 Linux 内核的 IO 栈里。

为了抓现行，直接祭出 perf top 观察内核态的 CPU 热点，结果满屏红彤彤的自旋锁：

  18.45%  [kernel]       [k] native_queued_spin_lock_slowpath
  12.30%  [kernel]       [k] blk_mq_sched_insert_request
   9.15%  [kernel]       [k] sbitmap_get
   7.20%  [kernel]       [k] dd_insert_requests

再看 CPU 状态，top 显示多核的 si（软中断）飙升，对应的进程全是 ksoftirqd/x。

愚蠢的配置与底层原理解析

走到这一步，根因已经水落石出：dd_insert_requests 这个函数的出现，意味着系统正在使用 mq-deadline IO 调度器。

查看设备的调度器配置，果不其然：

$ cat /sys/block/nvme0n1/queue/scheduler
[mq-deadline] kyber bfq none

为什么在 NVMe 上用 mq-deadline 是不可原谅的低级错误？

在 SATA/SAS 机械硬盘时代，磁盘只有一个硬件队列（Queue Depth 通常只有 32 或 256）。为了防止磁头剧烈寻道，Linux 内核设计了 IO 调度器（如 Deadline、CFQ）在软件层面对 IO 请求进行合并（Merge）和重排（Sort）。 但在 NVMe 时代，协议原生支持多达 64K 个硬件队列（Submission/Completion Queues），每个队列深度可达 64K。Linux 内核为此重构了 blk-mq（Block Multi-Queue）架构，将 CPU Core 与 NVMe 硬件队列直接建立映射关系（Software Queue -> Hardware Dispatch Queue）。

如果在 NVMe 上强行开启 mq-deadline 或 bfq，相当于在原本宽阔的双向 64 车道高速公路上，硬生生设了一个收费站。 所有并发请求走到 blk_mq_sched_insert_request 时，都需要去抢调度器内部的自旋锁，把请求塞进软件队列进行徒劳的合并尝试。在高并发的 KV 存储场景中，小块随机写极多，合并命中率极低，这种操作不仅毫无意义，反而引发了致命的锁争用（native_queued_spin_lock_slowpath）。同时，底层块设备完成 IO 后抛出的中断，在唤醒软中断处理（NET_RX / BLOCK）时又被上层阻塞，最终导致 ksoftirqd 把 CPU 吃干抹净。

极客实战：彻底打通 IO 栈

1. 拔掉收费站（关闭调度器）

直接将调度器设置为 none，让 blk-mq 完全旁路软件调度层，直通硬件队列。

echo none > /sys/block/nvme0n1/queue/scheduler

修改后，p99 延迟瞬间从 300ms 回落到稳定的 1.5ms，Load Average 下降 80%。

2. 防御性配置（根治固化）

永远不要相信手动命令，写进 udev 规则才是 SRE 的基本素养：

# /etc/udev/rules.d/60-io-scheduler.rules
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

（注：对 SATA SSD 依然保留 mq-deadline 是一种保守策略，但对 NVMe 必须一律为 none）。

3. 压榨最后一滴性能（中断亲和性）

即使调度器改成了 none，如果你发现某些 CPU 核的 hi/si 依然不均衡，那是因为 NVMe 的 MSI-X 中断没有打散。现代 NVMe 驱动通常会自动分配 IRQ，但如果运行了老旧的 irqbalance 守护进程，可能会发生“劣化漂移”。 建议针对极度依赖 IO 的节点，关掉 irqbalance，并使用内核源码自带的 set_irq_affinity 脚本将 NVMe 的完成队列中断静态绑定到 NUMA 节点的对应 CPU 核心上。

同类问题速查清单 (Troubleshooting Checklist)

  1. 检查 IO 调度器状态： 快速排查集群中所有块设备的调度器配置： awk -F'[][]' '{print $2}' /sys/block/*/queue/scheduler 如果 NVMe 设备输出非 none，立刻整改。

  2. 区分 OS 队列延迟与硬件延迟： 不要只看 iostat 的 await。使用 eBPF 工具（如 bcc-tools 的 biolatency）深入观测： biolatency -Q 若输出中 OS Queue Time (Q-time) 远大于 Device Time (D-time)，说明阻塞点在 Linux Block Layer。

  3. 检查 NVMe 多队列深度配置： 确认内核是否正确识别并启用了 NVMe 硬件队列： ls -d /sys/block/nvme0n1/mq/* | wc -l 该数值应接近或等于机器的 CPU 核心数。

  4. 观测软中断打散情况： watch -n 1 'cat /proc/interrupts | grep nvme' 观察各 CPU 列的数值增长率。如果只有极少数 CPU 在狂飙，说明 IRQ 绑定策略失效，正在引发单核软中断瓶颈。

更多文章