HDUO Lab

标签： io_uring

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

    某次核心存储网关进行底层 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 提交。

  • 深入 io_uring 延迟雪崩排查：O_DIRECT 缺失引发的 io-wq 线程池打满与 XFS 阻塞实战

    io_uring 并非异步 IO 银弹。在缺失 O_DIRECT 或执行 Append 写时，XFS 元数据锁会迫使 io_uring 降级至内核 io-wq 线程池。一旦线程池耗尽，主提交线程将陷入 D 状态，p99 延迟暴涨。核心解法：强制 Direct IO 并结合 fallocate 预分配文件块，彻底绕过元数据锁争用。

    某次排查一个基于 io_uring 重构的高并发存储网关（C++ 编写，运行于 Ubuntu 22.04，Kernel 5.15.0-82-generic，底层为 XFS v5 挂载）。该网关在压测阶段初期表现极佳，但当并发写入量达到 5000 QPS 时，系统 Load Average 瞬间飙升至 200+，p99 延迟从 2ms 劣化至惊人的 800ms。

    现场取证与指标异动

    首先看基础 IO 指标。通过 iostat 观察，磁盘的 %util 达到了 100%，但实际写入吞吐量（wMB/s）仅有可怜的 40MB/s，远未达到 NVMe SSD 的瓶颈。

    # iostat -x -d 1
Device            r/s     w/s     rMB/s     wMB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
nvme1n1          0.00 4820.00      0.00     38.50     0.00     0.00   0.00   0.00    0.00  182.50 142.10     0.00     8.18   0.21 100.00

    接着查看 CPU 状态，发现 iowait 极高，且存在大量的上下文切换（CS）。直接拉取进程状态，发现核心网关进程及其派生的内核线程大面积处于 D 状态（Uninterruptible Sleep）。

    # 查看 D 状态进程堆栈
$ for pid in $(ps -eo pid,state | awk '$2=="D"{print $1}'); do echo "PID: $pid"; cat /proc/$pid/stack; done

PID: 14205 (网关主线程)
[<0>] io_sq_thread+0x28a/0x560
[<0>] ret_from_fork+0x22/0x30

PID: 14221 (io_wqe_worker_0)
[<0>] xfs_ilock+0x105/0x220
[<0>] xfs_file_buffered_aio_write+0x142/0x3a0
[<0>] xfs_file_write_iter+0x7b/0xc0
[<0>] io_write+0xe4/0x310
[<0>] io_issue_sqe+0x39a/0x1e30
[<0>] io_wq_submit_work+0x12d/0x3b0
[<0>] io_worker_handle_work+0x153/0x290
[<0>] io_wqe_worker+0x2cd/0x350
[<0>] ret_from_fork+0x22/0x30

    内核堆栈直接暴露了致命问题：大量的 io_wqe_worker 线程阻塞在 xfs_ilock 上，且调用链明确显示走的是 xfs_file_buffered_aio_write（Buffered IO 路径）。

    为什么 io_uring 会在这个场景下退化为同步阻塞？

    很多研发对 io_uring 有个致命的误解，认为只要把 IO 丢进 SQE（Submission Queue Entry），内核就会纯异步处理。然而在 Linux VFS/文件系统层，真正的“非阻塞”是非常严苛的。

    当 io_uring 提交一个写请求时，它会默认带上 IOCB_NOWAIT 标志尝试“内联”（Inline）执行。

    1. 如果是 Direct IO (O_DIRECT) 且不改变文件大小（已分配块）：XFS 能够无锁直接下发 BIO，请求立即返回 EIOCBQUEUED，这是最完美的 Fast Path。

    2. 如果是 Buffered IO 或者需要改变文件大小（Append 写）：

    3. Buffered IO 需要分配 Page Cache，甚至触发内存回收，这在内核中是无法完全非阻塞的。
    4. Append 写需要分配新的磁盘 Block 并更新 Inode metadata，XFS 必须获取独占的 IOLOCK_EXCL 锁（即堆栈中的 xfs_ilock）。

    如果 XFS 发现无法 NOWAIT 完成，会向 io_uring 返回 -EAGAIN。io_uring 捕获到 -EAGAIN 后，会将这个 IO 任务打包，丢进内核后台的 io-wq 线程池（Slow Path）。

    在我们的高并发网关中，由于未设置 O_DIRECT，且业务在不断 Append 写新日志文件，导致：

    1. 所有的写请求都在 Fast Path 返回 -EAGAIN。

    2. io_uring 疯狂创建 io_wqe_worker 线程来接管任务。

    3. 这些 Worker 线程在执行 XFS 元数据更新时，由于抢占同一个 Inode 的 xfs_ilock，发生严重的锁排队。

    4. 内核 io-wq 线程池有并发上限（受限于 RLIMIT_NPROC 和内部调度机制），当线程池被打满后，io_uring 的主提交线程（如果启用了 SQPOLL，则是 io_sq_thread，否则是用户态的 io_uring_enter 系统调用）也会被迫阻塞。

    这就形成了经典的雪崩链路：Buffered IO/元数据写 -> EAGAIN -> io-wq 线程池爆炸 -> XFS 锁争用打满 IO 栈 -> 核心线程 D 状态阻塞。

    源码级溯源：XFS 与 io-wq 的死亡缠绕

    翻开 Kernel 5.15 的源码，我们可以清晰地看到这个降级逻辑：

    // fs/io_uring.c
static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags)
{
    // ...
    // 尝试执行写操作，带有 IOCB_NOWAIT
    ret = io_write(req, issue_flags); 

    // 如果底层文件系统返回 -EAGAIN，说明无法非阻塞完成
    if (ret == -EAGAIN && !(req->flags & REQ_F_NOWAIT)) {
        // 降级：将任务丢入 io-wq 后台线程池
        return io_queue_async_work(req, NULL);
    }
    // ...
}

    而在 XFS 层：

    // fs/xfs/xfs_file.c
STATIC ssize_t
xfs_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
    // 如果是 NOWAIT 且需要更新元数据/加锁失败，直接返回 -EAGAIN
    if (iocb->ki_flags & IOCB_NOWAIT) {
        if (!xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL))
            return -EAGAIN;
    }
    // ...
}

    破局之道：防御性 IO 架构改造

    要让 io_uring 发挥真正的 100K+ IOPS 威力，必须严防死守 Slow Path 降级。针对该网关，我们实施了以下三板斧改造：

    1. 强制启用 O_DIRECT 并对齐内存

    修改文件打开标志，彻底绕过 Page Cache。注意，使用 O_DIRECT 要求用户态 buffer 的内存地址和写入长度必须是块设备逻辑扇区（通常是 512 或 4096 字节）的整数倍。可以使用 posix_memalign 分配内存。

    // 改造前
int fd = open("data.log", O_WRONLY | O_CREAT | O_APPEND, 0644);

// 改造后 (移除 O_APPEND，加入 O_DIRECT)
int fd = open("data.log", O_WRONLY | O_CREAT | O_DIRECT, 0644);

    2. 利用 fallocate 预分配击穿 XFS 元数据锁

    由于去掉了 O_APPEND，我们要自己维护写入 Offset。更重要的是，为了避免每次写入都触发 XFS 的块分配（Block Allocation）导致获取 IOLOCK_EXCL，必须在文件创建时预分配足够大的空间。

    // 预分配 1GB 空间，保持文件 size 不变 (FALLOC_FL_KEEP_SIZE)
// 这样后续的 IO 都是纯数据覆写 (Overwrite)，XFS 只需要 IOLOCK_SHARED 甚至无锁下发
if (fallocate(fd, FALLOC_FL_KEEP_SIZE, 0, 1024 * 1024 * 1024) != 0) {
    perror("fallocate failed");
}

    3. 约束 io_uring 的退化行为 (非必须，但推荐)

    在初始化 io_uring 时，可以在 SQE 中显式设置 IOSQE_ASYNC，但这会强制走 io-wq，并非我们想要的。正确做法是依赖系统的默认行为，但通过上述 1 和 2 的改造，确保所有的 IO 都能在 Fast Path 成功，彻底饿死 io_wqe_worker 线程。

    改造后再次压测，5000 QPS 下 Load Average 降至 2.5，iowait 趋近于 0，p99 延迟稳定在 1.2ms，通过 ps 命令再也看不到海量的 io_wqe_worker 线程，系统恢复丝滑。

    常见问题

    Q1：除了 XFS，在 ext4 上使用 io_uring 也会遇到这个问题吗？ 会。无论 ext4 还是 btrfs，只要是 Buffered IO，或者涉及到文件 Append 写、打洞（Punch hole）、文件扩容，VFS 层都会面临元数据更新的锁保护。io_uring 遇到无法立即拿到的锁，统统会返回 -EAGAIN 并回退到 io-wq 线程池。这也是为什么高性能存储引擎（如 SPDK, ScyllaDB）坚决只用 O_DIRECT | O_DSYNC + AIO/io_uring 的原因。

    Q2：如何监控系统中 io_uring 的 io-wq 线程数量及退化情况？ 可以通过 eBPF 挂载内核探测点。一个简单的 bpftrace 脚本可以统计每秒降级到 io-wq 的请求数：

    bpftrace -e 'kprobe:io_queue_async_work { @[comm] = count(); } interval:s:1 { time("%H:%M:%S\n"); print(@); clear(@); }'

    如果看到你的核心业务进程疯狂触发该探针，说明你的 IO 栈配置存在严重问题，正在大量退化。

    Q3：我使用了 O_DIRECT，为什么 io_uring 的 p99 延迟偶尔还是会抖动？ 即使是 Direct IO，如果底层 NVMe 硬件队列打满，或者发生了 PCIe 链路层重传，依然会导致延迟上升。此外，XFS 默认开启了 speculative preallocation（推测性预分配），在某些碎片化严重的文件系统上，即便是对齐的覆写，也可能偶尔触发元数据刷新（Journaling），可以通过挂载参数 allocsize 进行微调，或者定期进行 xfs_fsr 碎片整理。

    Q4：启用 IORING_SETUP_SQPOLL 轮询模式能解决阻塞问题吗？ 不能。SQPOLL 只是内核启动一个专门的 io_sq_thread 去轮询你的 SQ 队列，省去了你发起 io_uring_enter 系统调用的开销（减少 syscall 上下文切换）。但如果底层的 XFS 依然因为锁争用返回 -EAGAIN，io_sq_thread 同样会将任务丢给 io-wq，甚至如果 io-wq 阻塞，io_sq_thread 自身也会陷入 D 状态，导致整个提交队列停摆。架构设计不能用并发去掩盖底层的串行锁。