Linux下io_submit延迟异常咨询：首次调用耗时远高于后续

嘿，这个现象我之前排查异步IO相关问题时也碰到过，本质是内核的懒初始化机制在起作用，我来给你拆解清楚：

先明确你的两种测试场景 #

场景1：连续调用io_submit #

#include <sys/time.h>
#include <libaio.h>

int main() {
    struct timeval start, end;
    io_context_t ctx;
    // 初始化AIO上下文（假设已完成）
    io_setup(10, &ctx);

    for (int i = 0; i < 5; i++) { 
        gettimeofday(&start); 
        // 这里省略具体的io_submit参数，比如提交一个简单的读/写请求
        io_submit(ctx, 1, ...); 
        gettimeofday(&end); 
        // 计算耗时并打印
        long usec = (end.tv_sec - start.tv_sec)*1000000 + (end.tv_usec - start.tv_usec);
        printf("io_submit耗时：%ld微秒\n", usec);
    }

    io_destroy(ctx);
    return 0;
}

输出结果：

io_submit耗时：9微秒
io_submit耗时：2微秒
io_submit耗时：2微秒
io_submit耗时：3微秒

场景2：每次调用后sleep #

（补全你未写完的代码）

for (int i = 0; i < 5; i++) { 
    gettimeofday(&start); 
    io_submit(ctx, 1, ...); 
    gettimeofday(&end); 
    long usec = (end.tv_sec - start.tv_sec)*1000000 + (end.tv_usec - start.tv_usec);
    printf("io_submit耗时：%ld微秒\n", usec);
    sleep(1); // 添加sleep操作
}

推测输出会是每次耗时都接近首次的9微秒，而非连续调用时的低耗时。

核心原因：首次调用的内核懒初始化 #

当你第一次调用io_submit时，内核需要完成一系列一次性的初始化工作：

• 创建并初始化AIO上下文对应的内核数据结构
• 启动异步IO处理的内核线程池（传统Linux AIO依赖内核线程来处理异步请求）
• 建立用户态与内核态的资源映射（比如请求队列、内存缓冲区的映射）
• 如果是动态加载的内核模块，还会触发模块加载

这些操作都需要额外的CPU和内存开销，所以首次调用的延迟会明显高于后续调用。而连续调用时，内核已经完成了初始化，直接复用已有的资源，所以耗时骤降。

为什么加sleep后会回到高耗时？ #

当你在每次调用后加入sleep(1)，内核会认为当前AIO上下文处于空闲状态，会回收相关的资源（比如销毁闲置的内核线程、释放部分上下文缓存）。当下一次调用io_submit时，内核又需要重新执行初始化流程，导致耗时再次升高。

验证与优化思路 #

1. 预热验证 #

在正式业务逻辑前，先做一次“预热”调用：

// 预热：提交一个空的或者无效的请求，触发内核初始化
io_submit(ctx, 0, NULL);
// 然后再执行正式的循环调用
for (int i = 0; i < 5; i++) { ... }

这样后续的正式调用都会复用已初始化的资源，耗时会保持在低水平。

2. 调整内核参数（针对传统libaio） #

• 修改/proc/sys/fs/aio-max-nr：增大允许的最大AIO请求数，避免内核频繁回收资源
• 部分内核版本可以调整异步线程池的空闲超时时间（比如通过内核参数或sysctl），延长资源存活时间

3. 切换到io_uring #

如果你的内核版本≥5.1，强烈建议切换到io_uring——这是Linux新一代异步IO实现，它的初始化开销更低，性能更稳定，且避免了传统AIO依赖内核线程的诸多问题。

4. 资源保活（针对必须sleep的场景） #

如果业务场景必须有长时间间隔的AIO调用，可以定期发送一个空的AIO请求（比如每隔几百毫秒），让内核认为资源在被使用，避免被回收。

内容的提问来源于stack exchange，提问作者haipeng31