为什么需要绕过 Page Cache

• 传统 I/O 方法回顾 Linux 在 read/write 时会先将数据放到 Page Cache 再同步到磁盘。这样虽然利用了局部性，但也产生了额外复制。按理说，

text app write → User Buffer → → Kernel Page Cache → → Disk

• 双重缓冲问题 数据库自身拥有 buffer pool。又有 kernel 页表。当 InnoDB 从磁盘取页时会出现：

text Disk → Kernel Cache ←→ InnoDB Pool

同一页在两处复制导致大量无用 memory。

• 内存拷贝成本 每次 read/write 都要执行一次 memcpy；老实说，当吞吐量达 GB/s 时这些复制几乎占用了全部 CPU 与带宽。

• cache 污染 顺序扫描、备份等任务把大量非热点数据塞进 Page Cache从而把热点页面挤掉；后续查询性能骤降，

• 何时保持 page cache - 小文件频繁访问 - 多进程共享只读同一文件 - 无自建 cache 的轻量级工作负载

O_DIRECT 的语义与实现

1. 开启方式 c int fd = open; Linux 特有 macOS 用 fcntl.

2. 对齐要求

   • 缓冲区地址、文件偏移、传输长度均需按 logical block size 对齐。
   • 不满足返回 EINVAL.

   c posix_memalign;// 推荐做法

3. 内部方法

O_DIRECT 避免了 kernel‑user copy，也省掉了 Page Cache 所占用的物理 RAM。

对齐错误实例

c char *unaligned = malloc;write，// EINVAL

通过 strace -e write …怎么说呢，| grep EINVAL 可快速定位对齐问题。

写入持久化

O_DIRECT 并不能保证“立即持久”，因为仍可能驻留在硬件写 cache。再看必须配合，

c write;fsync，// 或 fdatasync

或者打开时使用 O_SYNC | O_DIRECT。

各数据库 Direct‑IO 策略

常见陷阱与限制

1. 混合使用 – 同一 inode 上同时使用普通 + O_DIRECT 会产生不可预测结果； 若必需混用，请先执行 fsync。
2. 特殊 FS 行为差异 – tmpfs 忽略 O_DIRECT;NFS/VFS 与 FUSE 对齐细节不同。
3. 随机小尺寸读低效 – 没有自建 cache 时小随机读往往比普通 IO 慢。
4. 元数据信息仍走 cache – rename/mkdir 等仍需 fsync 保证。
5. ext4/xfs 行为差异 – ext4 在 /日志提交上更严格；xfs 更友好且可结合 fallocate。老实说，

性能对比概览

• 顺序写入普通 IO 通常略快但 CPU 占比高；O_DIRECT 延迟更稳定，无 flush 峰值。
• 随机读取若已热化，则普通 IO 几乎无差距；冷态下两者接近，但前者因 memcpy 开销略高。
• *数据库 OLTP/OLAP 测试 *启用 innodb_flush_method=O_DIRECT 可减少 ~20% 内存使用并提高 TPS 若 buffer pool 覆盖工作集。

替代方案

1. io_uring + direct‑IO – 异步批量提交，但仍需满足对齐。并配合 IORING_REGISTER_BUFFERS.
2. DAX / PMEM mmap – 完全跳过 OS 层，只适用于持久性 RAM 与专门库支持。
3. FUSE Passthrough Mode – 当底层 FS 已支持 direct‑IO 时可直接转发请求。

使用者痛点

• 大规模部署下 double buffering 导致显著 RAM 消耗与 GC 压力。
• 难以调试对齐错误，每次报错都隐藏于 “EINVAL” 字符串之下。
• 混合 IO 模式产生脏乱状态，需要手动同步才能保证一致性。

是否应开启 Direct‑IO。还有如何正确配置与调优，以获得最佳性能与可靠性。