高并发写入场景下，NVMe 盘配合 XFS 极易触发 sys CPU 满载与 IO 夯死。核心原因是 NVMe 误用了 mq-deadline 调度器，导致 blk-mq 软件队列自旋锁争用，进而引发 XFS 分配元数据时在 xfs_log_commit_cil 处发生锁雪崩。直接结论：NVMe 设备的 IO 调度器必须设为 none，同时对于高并发盘，需在格式化时调大 XFS 的 agcount 以打散锁粒度。
故障现场：数据库写入 p99 突增与 sys CPU 飙升
某次排查过程中，一套承载核心业务的 PostgreSQL 集群（内核版本 5.10.134-el8，底层存储为裸金属物理机的 PCIe Gen4 NVMe SSD）在高并发 COPY 导入数据时，QPS 出现周期性断崖式下跌。
通过 top 观察，CPU sys 态长期飙升至 70% 以上，iowait 反而在 10% 左右波动。这极不寻常——对于一块标称 100万 IOPS 的 NVMe 盘，IO 没有跑满，CPU 却在内核态被榨干。
抓取当时的 iostat -x 1 核心指标：
Device: r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 12.0 42351.0 192.0 680512.0 0.0 0.0 0.0 0.0 0.15 18.42 12.5 16.00 16.06 0.02 85.40
注意 w_await 达到了惊人的 18.42ms，对于 NVMe 来说，这个延迟意味着底层已经严重阻塞。但 %util 只有 85%，设备并未完全饱和。
使用 perf top -U 直接看内核态热点，现场如下：
18.45% [kernel] [k] queued_spin_lock_slowpath
12.31% [kernel] [k] dd_insert_requests
8.52% [kernel] [k] xfs_log_commit_cil
6.14% [kernel] [k] blk_mq_submit_bio
5.33% [kernel] [k] _raw_spin_lock_irqsave
热点非常集中：dd_insert_requests 和 xfs_log_commit_cil。这表明系统同时在块设备调度层和文件系统日志提交层发生了严重的锁争用。
为什么 NVMe 设备使用 mq-deadline 会导致 IO 栈雪崩？
问题出在 Linux blk-mq（Block Multi-Queue）架构的调度器选择上。
在传统的单队列（Single Queue）时代，所有 IO 请求进入一个全局队列，需要 CFQ 或 Deadline 这种电梯算法（Elevator）进行合并和排序，以减少机械硬盘的磁头寻道。
到了 NVMe 时代，硬件支持多达 64K 个提交/完成队列。Linux 为此重构了 blk-mq 架构，分为软件队列（Software Staging Queues，通常每个 CPU 核心一个）和硬件分发队列（Hardware Dispatch Queues）。
排查发现，该服务器的 NVMe 被默认配置了 mq-deadline 调度器：
$ cat /sys/block/nvme0n1/queue/scheduler
[mq-deadline] kyber bfq none
底层阻塞原理：
当调度器设置为 mq-deadline（甚至 bfq）时，IO 请求在进入硬件队列前，必须先挂载到电梯算法的软件队列中。dd_insert_requests 就是 mq-deadline 插入请求的内核函数。由于高并发下成千上万个线程试图向这个软件队列提交 BIO（Block I/O），这就不可避免地触发了自旋锁（queued_spin_lock_slowpath）。
NVMe 的纳秒级响应速度完全被软件队列的自旋锁开销抹平，导致 CPU 在 sys 态空转，IO 提交路径被硬生生卡住。
剥茧抽丝：XFS 延迟分配与 AIL/CIL 阻塞
块设备的延迟飙升，迅速引发了文件系统层的连锁反应，这也是为什么 perf 中出现了大量 xfs_log_commit_cil。
XFS 是一种强依赖 Allocation Group（AG）并发设计的日志文件系统（当前版本 V5）。当数据库执行大量写入时，XFS 会利用延迟分配（Delayed Allocation）机制，在内存中缓存数据，直到刷盘时才真正分配物理 Block 并更新元数据。
-
CIL（Committed Item List）雪崩：元数据变更首先写入内存中的 CIL。当底层 NVMe 因为
mq-deadline阻塞时，后台刷脏线程（xfsaild）将 AIL（Active Item List）刷入磁盘的速度骤降。 -
AG 锁争用：CIL 空间被占满，前端业务线程在调用
xfs_alloc_vextent申请新的空间块时，必须等待日志空间释放。大量 PostgreSQL 线程被迫在同一个 AG 的元数据锁上排队。 -
全局夯死：IO 栈的阻塞放大了 XFS 的锁临界区时间，最终导致原本并行的 IO 瀑布般退化为串行等待，形成死锁态势的雪崩。
解决方案与防御性配置
解决该问题不需要修改业务代码，纯属系统级架构调优，分为治标和治本两步。
1. 立即剥离软件调度器（实时恢复）
将 NVMe 设备的调度器强行切换为 none，绕过所有电梯算法，让 BIO 请求直接从软件多队列打入硬件队列。
echo none > /sys/block/nvme0n1/queue/scheduler
执行瞬间，sys CPU 从 70% 骤降至 8%，PostgreSQL QPS 恢复正常，w_await 回落至 0.05ms。
为了防止重启失效，通过 udev 固化防御策略：
# vim /etc/udev/rules.d/60-io-scheduler.rules
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
2. XFS AG 并发度调优（底层重构）
默认情况下，mkfs.xfs 根据磁盘大小自动计算 agcount（通常是 4 或 8）。对于大容量、极高吞吐的 NVMe 盘和数据库场景，默认 AG 数量太少，容易发生并发分配碰撞。
在节点下线重装阶段，调整格式化参数，人为扩大 AG 数量打散锁粒度：
# 格式化 XFS：强制启用 32 个 AG，对齐 512M 日志大小
mkfs.xfs -f -K -d agcount=32 -l size=512m,version=2,su=256k /dev/nvme0n1
注：agcount 并非越大越好，过大会增加 mount 时间和内存开销，通常 16-32 针对高端 NVMe 是甜点区间。
常见问题
Q1: io_uring 在遇到这种 XFS 锁争用时，会退化成同步阻塞吗？
会。这是很多人使用 io_uring 踩坑的地方。虽然 io_uring 是异步 IO，但如果在文件系统层发生 metadata 锁争用（比如 XFS 分配 block），底层的 IORING_OP_WRITE 且带有 RWF_NOWAIT 标志位时，内核会直接返回 -EAGAIN。随后 io_uring 只能将这个 IO 任务推入后台的 io_worker 线程池进行同步阻塞处理，纯异步链路被击穿，高并发下依然会导致线程池耗尽。
Q2: 调度器设置为 none 后，系统还有 IO 合并能力吗？
有，但发生在不同层级。none 确实禁用了电梯算法层的合并，但 blk-mq 在软件队列层（Software Staging Queue）和块设备硬件驱动层依然会利用 scatter-gather list 进行有限的相邻物理段合并。对于 NVMe 而言，本身 4K 随机 IO 的性能极高，强行进行复杂的 IO 合并排序带来的 CPU 锁开销远大于其收益。
Q3: 如何在生产环境无损监控 XFS 的 AG 锁争用情况？ 极力推荐使用 eBPF/bpftrace 而不是 SystemTap。可以通过挂载 tracepoint 实时监控 CIL 提交延迟：
bpftrace -e 'tracepoint:xfs:xfs_log_commit_cil { @start[tid] = nsecs; } tracepoint:xfs:xfs_log_commit_cil_wait { if(@start[tid]) { @usecs = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); } }'
如果输出的直方图显示大量调用耗时超过 1000 微秒（1ms），说明文件系统日志提交已出现严重积压，需立即排查底层块设备延迟。