从MMAP到io_uring：一次让性能变慢的优化实验

一次反直觉的性能实验

在系统性能优化的世界里，我们常常被各种"新技术更快"的宣传所包围。io_uring 作为 Linux 内核近年来最受关注的异步 I/O 接口，被普遍认为能够大幅提升 I/O 密集型应用的性能。然而，一支使用 Rust 构建查询引擎的团队却分享了一个反直觉的实验结果：当他们用 io_uring 替换掉传统的 MMAP（内存映射）方案后，系统反而变慢了。

这个案例之所以值得深入探讨，正是因为它挑战了工程界的"技术崇拜"——并非所有先进的技术都能在任何场景下带来性能收益。技术选型永远是场景与权衡的艺术。

理解两种I/O方案的本质差异

MMAP：让文件像内存一样访问

MMAP（Memory-Mapped File）是一种将文件直接映射到进程虚拟地址空间的技术。对于查询引擎而言，MMAP 的最大优势在于它把 I/O 的复杂性交给了操作系统内核处理。

当查询引擎需要读取数据时，它只需像访问普通内存一样访问映射区域，内核会通过缺页中断（page fault）机制按需将磁盘数据加载到页缓存（page cache）中。这种方式的好处显而易见：

• 零拷贝：数据不需要在内核缓冲区和用户缓冲区之间来回拷贝
• 自动缓存：操作系统的页缓存机制会自动管理热数据
• 编程简单：开发者无需手动管理 I/O 请求的生命周期

io_uring：现代异步I/O的代表

io_uring 是 Linux 5.1 引入的异步 I/O 框架，通过提交队列（SQ）和完成队列（CQ）两个环形缓冲区，实现了用户态与内核态之间高效的批量 I/O 通信。它的设计初衷是解决传统 AIO 接口的种种限制，理论上能够以极低的系统调用开销处理海量并发 I/O 请求。

在高并发、大吞吐的存储场景中，io_uring 往往能够展现出显著的性能优势，这也是它备受推崇的原因。

为什么替换后反而变慢了

虽然原文的技术细节有限，但从系统工程的角度，我们可以合理推断出几个关键原因。

页缓存的隐形优势被丢弃

使用 MMAP 时，查询引擎实际上是站在操作系统页缓存这个"巨人的肩膀"上。对于查询引擎这类工作负载，往往存在大量重复访问的热数据。MMAP 让这些数据天然地驻留在页缓存中，后续访问几乎是纯内存操作，速度极快。

而切换到 io_uring 后，如果团队使用了 O_DIRECT 直接 I/O 来绕过页缓存，就意味着放弃了这层免费的缓存加速。除非应用层实现了同样高效的缓存机制，否则每次读取都要真正触及存储设备。

系统调用与批处理的错配

io_uring 的性能优势建立在批量提交、异步完成的模型之上。它最擅长的场景是同时处理成百上千个并发 I/O 请求，通过一次系统调用批量提交来摊薄开销。

然而，如果查询引擎的访问模式本质上是相对随机、小批量的读取，那么 io_uring 的批处理优势就无从发挥，反而引入了额外的队列管理、请求构造和完成事件轮询的开销。

数据拷贝与内存管理的额外成本

MMAP 的零拷贝特性意味着数据加载后可以直接被查询逻辑使用。而使用 io_uring 通常需要预先分配读取缓冲区，数据从设备读入这些缓冲区后，可能还需要额外的处理才能供上层逻辑消费。在数据量较大时，这些内存分配和拷贝成本会逐渐累积。

这个案例给我们的启示

没有银弹，只有适配

这个实验最核心的教训是：技术的优劣永远相对于具体的使用场景。io_uring 是优秀的技术，MMAP 也是经过时间检验的方案，两者各有擅长的领域。查询引擎的访问模式、数据规模、并发特征，共同决定了哪种方案更合适。

性能优化必须以测量为前提

这支团队最值得称赞的一点，恰恰是他们真正做了对比测试，而不是盲目相信"新技术更快"的假设。在没有实际测量数据之前，任何性能优化都只是猜测。正如计算机科学家 Donald Knuth 的名言："过早优化是万恶之源。"

敢于分享"失败"的价值

在技术社区中，成功案例总是被大量分享，而"我们尝试了却失败了"的经验却相对稀缺。这类负面结果的分享同样宝贵——它帮助其他工程师避免重蹈覆辙，也提醒我们保持对技术的批判性思考。

结语

从 MMAP 到 io_uring 的这次"失败"实验，与其说是 io_uring 的失败，不如说是一次成功的工程验证。它用真实的数据告诉我们：在数据库和查询引擎的世界里，操作系统页缓存与 MMAP 的组合依然是一个强大且难以轻易超越的基线。

对于任何考虑引入新 I/O 技术的团队来说，这个案例都是一个及时的提醒：在动手替换之前，先充分理解你的工作负载特征，然后用严谨的基准测试来验证每一个假设。真正的性能工程，永远建立在测量而非信仰之上。