HDUO Lab

深入 io_uring 陷阱排查：Buffered IO 回退引发的 io_wq 耗尽与 XFS D状态假死实战

作者：

ningniu

在

某次核心存储网关进行底层 IO 引擎重构，开发团队信誓旦旦地将传统的线程池同步读写替换为 io_uring，期望实现吞吐量的降维打击。结果上线灰度不到半小时，节点 Load Average 直接飙到 300+，QPS 从 5w 呈断崖式暴跌至 300，P99 延迟更是惨不忍睹地拉平到了 8 秒以上。

最终结论先行： 这是一起典型的“只懂调用 API，不懂内核 IO 栈”引发的惨案。开发团队在使用 io_uring 提交读写任务时，文件句柄没有开启 O_DIRECT，导致 IO 操作回退为 Buffered IO。 在高并发写压迫下，大量 io_uring 任务因触发内核 Page Cache 分配阻塞或 XFS inode 元数据锁（xfs_ilock），被强行剥离给 io-wq 工作线程池同步执行。最终，所有 io-wq 线程全部陷入 D 状态（Uninterruptible Sleep），整个异步 IO 引擎彻底退化为大规模的同步锁竞争现场，引发系统级假死。

修复方案： 文件打开必须携带 O_DIRECT 标志位，并确保应用层内存按照块设备扇区大小（通常 512B 或 4KB）对齐，彻底绕过 Page Cache，让 io_uring 真正走到底层块设备的异步 DMA。

故障现场：安静的 CPU 与暴走的 Load

排查过程中，第一眼看监控面板是非常诡异的：CPU 整体使用率（us+sy）不到 15%，但 wa (iowait) 却高达 60%。同时，Load Average 突破天际。

通过 iostat -x 1 观察到底层 NVMe 盘的状态：

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
nvme1n1          12.0  2540.0     192.0  128500.0     0.0     0.0    0.0    0.0    0.80  145.20  280.50    16.00    50.59   0.38 100.00

IOPS 只有 2000 出头，带宽 120MB/s 远未达到 NVMe 的瓶颈，但 %util 已经被打满到 100%，aqu-sz (队列深度) 严重积压。

切到机器上，揪出一个处于 D 状态的业务进程，直接看它的内核调用栈：

cat /proc/`pidof storage-gateway | awk '{print $1}'`/task/*/stack | grep -A 5 -B 5 "xfs_ilock"

满屏类似的堆栈：

[<0>] xfs_ilock+0x135/0x250 [xfs]
[<0>] xfs_file_buffered_write+0xe4/0x300 [xfs]
[<0>] new_sync_write+0x114/0x1a0
[<0>] vfs_write+0x1d5/0x270
[<0>] io_write+0xe5/0x340
[<0>] io_issue_sqe+0x5c/0x1c0
[<0>] io_wq_submit_work+0x8f/0x290
[<0>] io_worker_handle_work+0x153/0x2e0
[<0>] io_wqe_worker+0x2c6/0x370
[<0>] ret_from_fork+0x1f/0x30

深度扒皮：io_uring 的异步伪装术

看到 io_wqe_worker 和 xfs_file_buffered_write 同时出现，基本就可以断定这是一场由 Buffered IO 引起的血案了。

很多开发者对 io_uring 存在不切实际的幻想，认为只要把 read/write 系统调用换成 io_uring_enter，内核就会施展魔法让一切变成异步。在 Linux VFS 层，如果文件未按 Direct IO 打开，所有的写入都要先进入 Page Cache。

当内存充足且未触发回写时，Buffered Write 确实快；但当系统内存吃紧，或者高并发引发 XFS 锁竞争时（比如同时追加写入同一个文件需要获取 xfs_ilock 排他锁），当前上下文就会被阻塞。

io_uring 设计之初就考虑到这一点。为了防止提交队列（SQ）的轮询线程被内核级锁卡死，内核态的 io_uring 调度器做了一个妥协：当发现当前操作可能阻塞（比如 Page Cache 未命中或需要拿 VFS/文件系统锁）时，它会立刻返回 -EAGAIN，并将这个 SQE（提交队列实体）打包扔给后台的 io-wq（内核工作线程池）。

这就是为什么我们在堆栈里看到了 io_wq_submit_work。开发者的本意是实现数万并发的无阻塞 IO，结果全被内核降级成了 io-wq 线程池的同步阻塞。当 io-wq 的线程被全部卡死在 xfs_ilock 等待上时，新的 IO 请求无处安放，应用层 io_uring 队列被打满，最终导致全局雪崩。

为什么 XFS 锁竞争如此激烈？ 在该场景中，业务是海量的小包追加写（Append Write）。在 XFS/Ext4 中，Append 写不仅需要分配新的块，还要更新 Inode 的 i_size 元数据。这意味着必须要拿 xfs_ilock 的互斥锁（Exclusive Lock）。没有 Direct IO，没有对齐的并发大块写入，海量的小 Buffered Write 硬生生把高性能文件系统逼成了串行处理机。

避坑与防御性配置

把 F1 赛车开进泥潭，然后抱怨车速慢，这是对现代内核 IO 栈最大的侮辱。要真正榨干 io_uring 和 NVMe 的性能，必须遵循严苛的规则。

  1. 强制开启 O_DIRECT： 这是使用 io_uring 处理文件 IO 的基石。 c int fd = open("data.db", O_RDWR | O_DIRECT | O_DSYNC); 只有使用 O_DIRECT，内核才会跳过 Page Cache，通过 get_user_pages 锁定用户态内存，直接将其映射给块设备的 DMA 引擎。这时候，io_uring 才会在块层真正的异步回调结束时产生 CQE（完成队列实体），绝对不会阻塞提交线程。

  2. 严格的内存对齐（Memory Alignment）： 开启 Direct IO 后，用户态用于承载读写的 Buffer 内存地址，以及写入的 offset 和 length，必须是底层块设备逻辑扇区大小（通常为 512B 或 4096B）的整数倍。 c void *buffer; // 假设 4K 扇区对齐 if (posix_memalign(&buffer, 4096, 4096) != 0) { // error handling }

  3. 配合 XFS 的 Extent 预分配： 如果是频繁追加写，即便用了 O_DIRECT，扩展文件大小依然会触发元数据锁争用。极客的做法是使用 fallocate 预分配大块文件空间，将 Append Write 转变为 Overwrite，彻底消除写入过程中的 xfs_ilock 竞争。

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

  1. 核对 D 状态调用栈：使用 cat /proc/$(pidof YOUR_APP)/task/*/stack | grep -i wqe，如果大量出现 io_wqe_worker、file_buffered_write、xfs_ilock、folio_wait_bit，百分百是未开启 O_DIRECT 导致的回退阻塞。

  2. 审查 O_DIRECT 标记：使用 strace -p $PID -e openat 或通过 lsof -p $PID 观察 FD，确认核心数据文件是否均带有 O_DIRECT 标志。

  3. 排查系统 io-wq 线程数量：当 io_uring 降级时，会创建大量 iou-wrk 线程。ps -ef | grep iou-wrk 若输出成百上千行，说明你的异步引擎已经彻底退化为同步线程池。

  4. 验证 XFS 元数据碎片：执行 xfs_bmap -v /path/to/file，如果一个文件的 extents 碎片高达几十万个，说明缺少 fallocate 预分配，导致文件系统元数据分配严重拖慢 IO 提交。

更多文章