操作系统内功 · 第 45 篇｜readahead 预读：页缓存读路径的启发式与 posix_fadvise

顺序读的困境与预读的直觉

第 4 篇讲过，Linux 的所有文件读都先经过 Page Cache，磁盘只是缓存未命中时的后端。这一篇补上读路径里最精巧的一环：预读。先算一笔账：程序按 4KB 一页发起 read，一次调用的真实成本包括系统调用陷入、上下文切换、文件系统路径查找与块层请求提交，最后还要等介质返回。机械盘一次寻道几毫秒，SATA SSD 几十微秒，NVMe 虽然只要几微秒，但每次调用一两微秒的软件开销同样省不掉。如果每一页都同步等结果再读下一页，吞吐上限就被单次延迟死死钉住：按五十微秒一页估算，最快也不过八十兆字节每秒，远低于介质本身的顺序带宽。问题的解法往往不是把盘换得更快，而是减少等待的次数。

预读（readahead）赌的是空间局部性。日志回放、备份拷贝、数据文件全表扫描这类负载，读完第 N 页之后极可能接着读第 N+1 页。内核在应用只请求一小块时，悄悄把后续若干页一并读进缓存：赌对了，应用下一次 read 直接从内存命中，不必等盘；赌错了，多读的页白占内存、白耗带宽。所以预读窗口必须自适应——访问模式顺序就扩张，出现乱序就收缩。这套启发式在内核里运行了二十多年，是页缓存读路径真正的性能核心。

把收益量化一下：预读窗口充分扩张后，一次从盘里拉取 128KB 甚至 1MB，同样的 1GB 文件所需的 IO 次数从二十五万次缩到几千次，系统调用、队列与中断开销同步下降。反过来，如果负载是每秒几千次的随机点查，预读就是纯浪费：每次都顺手读几 MB 没人问津的邻页，内存与带宽双输，还可能把别人的热数据挤出缓存。判断自己的业务属于哪一类，是动手调优之前必须完成的第一步。

内核里的窗口算法：扩张、收缩与双流误判

内核为每个打开文件维护一份预读状态（file_ra_state），记录当前窗口起点、窗口大小与异步触发线。当应用读到一个尚未缓存的页时，内核除了把请求页读进来，还顺手把窗口内后续若干页一起拉入缓存，并在页上打标记区分「应用要的页」与「预读的页」。首次访问一个新文件时窗口很小，内核先用小规模试探确认顺序性，而不是一上来就豪赌，这个克制的开局让随机负载不至于一开始就被大窗口误伤。

扩张规则很有性格：当应用读到窗口尾部那批带异步标记的页时，内核把「顺序假设得到验证」翻译成行动——立刻发起下一轮预读，窗口尺寸翻倍，从几页到十几页一路指数增长，直到上限（由块设备 bdi 的 read_ahead_kb 参数限定）。这就是「赌对了就加注」。反之，若应用在窗口读完之前就跳去了别的偏移，说明顺序假设失败，窗口减半甚至清零重新试探；若访问始终随机乱跳，窗口会长期停在最小值，实际退化为按需单页读。整套算法没有魔法，就是一套基于命中反馈的在线赌博策略。

这套启发式有两个著名盲区。其一是双流交错：两个线程在同一个文件上交替前进，彼此的跳跃会互相干扰，窗口判断在「顺序」与「乱序」之间反复横跳，最后两边都拿到可怜的小窗口。数据库后台全表扫描与在线点查混跑、同一存储上多路日志交错回放，都是典型受害场景。其二是 mmap 读走的是另一条路：缺页驱动下的 faultaround 逻辑会把缺页地址周围一圈一并建立映射，对顺序扫描同样有效，但它的窗口语义与 read 路径不同，观测和调优要分开看待。

还有一点常被忽略：预读只对「尚未缓存」的页有意义。文件已经全在内存里时，read 直接命中缓存，预读逻辑近乎旁路。所以预读调优只在冷读、大文件、高吞吐场景才有杠杆；缓存全热的小型数据集，怎么调参数都不会有肉眼可见的差别。另一个实用推论是：预读窗口对「应用层已经自己做缓冲池」的软件（比如自带 16GB buffer pool 的数据库）意义要打个折扣，因为热数据早已由应用层缓存兜住，内核窗口只对冷区扫描生效。

双流误判并非无解，工程上有三条补偿路径。最直接的是让应用自己做大块读：一次 read 拉取 1MB 以上，每次调用本身就跨越几十个页，窗口启发式的判断失误被应用层的批量冲抵——许多高性能数据扫描工具走的正是这条路。其次是打 RANDOM 标记主动关小窗口，承认乱序、按需直读，把确定性握在自己手里。第三是把交错流物理隔离：不同文件、不同盘、甚至不同时间窗，让每个流独享启发式的完整注意力。内核的多流状态跟踪也在持续改进，但应用层的这三条路径至今仍是可靠的主力。

posix_fadvise：把负载先验交给内核

内核启发式猜得不错，但它毕竟是猜。应用自己最清楚自己的访问模式，posix_fadvise 就是官方给的上报通道：调用 posix_fadvise(fd, offset, len, advice)，告诉内核这段区间「我将顺序读」「我将随机读」「马上要读」或「读完就别留了」。glibc 提供封装，各档建议语义明确，是高性能文件工具的标配接口，也是应用层纠正内核误判的正规手段。

常用档位里，POSIX_FADV_SEQUENTIAL 把该文件的预读上限翻倍，窗口扩张更激进，适合备份、日志归档、视频转码这类纯顺序大流量；POSIX_FADV_RANDOM 反向操作，把窗口压到几乎为零，让随机点查不被无谓的邻页 IO 拖累。POSIX_FADV_WILLNEED 让内核立刻按当前窗口发起预读——读请求提交进块层但不等待完成，适合「我知道三秒后要读这十兆，现在先把 IO 排上队」的节奏控制。POSIX_FADV_DONTNEED 把指定区间的干净页从页缓存摘除，是各种 dump 工具防止缓存自污染的标准动作。

工程实践里有大量现成范例。mysqldump、pg_dump 一类逻辑备份工具会吐出巨大的 SQL 流，读表数据本身是顺序的，但几百 GB 的数据页一旦全部涌入页缓存，就会把在线业务的缓存挤出去，形成备份拖垮主库的经典事故。稳妥做法是边读边对已读区间调用 DONTNEED，让备份流量「读完即走」。rsync 与 GNU cp 的实现里同样有 fadvise 的身影：对顺序比对区间用 SEQUENTIAL 与 WILLNEED 组合预热，读完一段就释放一段。自己写数据迁移脚本时，接入这几个建议值通常只要十几行代码，收益却立竿见影。

注意事项有三条。第一，DONTNEED 只能摘干净页，脏页要等回写完成才能释放，所以「写完立刻 DONTNEED」对刚写的数据并不生效。第二，fadvise 作用于 inode 级的页缓存而非进程私有缓存，同一个文件的其他读者也会受影响——既是特性也是隐患，在共享文件上盲目打 RANDOM 标记会误伤别人的顺序读。第三，对 mmap 映射区间，WILLNEED 仍会发起预读，但 DONTNEED 在不同内核版本上的行为存在差异，生产依赖前建议实测验证，不要只看文档。

云环境把预读的杠杆进一步放大。网络块设备的每次 IO 都要付一次网络往返的税，往返耗时一两毫秒很常见，小窗口顺序读的吞吐被往返延迟死死压住；把窗口放大到 1MB 以上，同样的往返次数搬运多一个数量级的数据，吞吐提升远比本地盘明显——云数据库厂商普遍调大实例的预读参数，正是这笔算术。反过来，云盘的突发带宽与额度机制也让激进预读有代价：预读拉来的页若无人问津，消耗的是真金白银的带宽额度，性能与账本要一起看。

块层参数与观测手段

预读窗口的物理上限由块设备的 bdi 决定，全局默认出口是 vm.read_ahead_kb，多数发行版默认 128KB。要特别注意它的生效语义：这个 sysctl 只影响之后新建的设备队列，对已经在线的设备不生效。运行中的设备要改各自 /sys/block 目录下 bdi 里的 read_ahead_kb 文件，或者用 blockdev --setra 命令（其单位是 512 字节扇区，写 2048 即 1MB）。RAID 阵列上窗口应与条带宽度对齐：比如八块数据盘、每条带单元 256KB 的 RAID6，一个完整条带就是 2MB，把预读窗口设为 2MB 能让每次 IO 恰好铺满一条带，减少跨条带的碎读，这是存储厂商手册里的经典建议。

观测有两条路。粗粒度用 iostat 的扩展输出：看每秒读请求数与读吞吐的比值，顺序负载充分预读时平均单次请求尺寸应接近窗口大小；如果请求数极高而单次只有 4KB，说明预读没有生效，或者负载本身就是随机的。细粒度用 BCC 工具集的 biosnoop 跟踪每个块层请求的扇区号、尺寸与延迟，能直接看出请求是连续大块还是碎片化小 IO，配合第 34 篇的观测工具箱使用效果更好。

经验数字可以参考：机械盘上的顺序备份把预读窗口从 128KB 提到 1MB，tar 或 dd 一类工具的吞吐常见百分之几十的提升；NVMe 上提升幅度小一些，主要省的是系统调用与队列开销；而在纯随机读的 KV 存储上盲目调大窗口，实测往往内存上涨、命中率下跌，属于负优化。改参数之前先用 fio 之类工具验证负载形态，比拍脑袋可靠得多。验证方法也很朴素：固定访问模式跑一组基线，改窗口再跑一组，对比吞吐与平均请求尺寸两个指标就够了。

实操清单与常见误区

给运维与开发一份可直接执行的清单。顺序大流量场景（备份、迁移、日志归档）：工具层接 SEQUENTIAL 加 WILLNEED 预热，读完用 DONTNEED 释放；系统层把在线设备的预读窗口提到 1MB 量级并对齐条带。随机点查场景：保持默认窗口，甚至在应用侧对大文件先打 RANDOM 标记。数据库场景重点防备份自污染，dump 路径务必接 DONTNEED，必要时给备份工具单独限速，别让它独占缓存带宽。

常见误区集中列一下。误区一：改了 vm.read_ahead_kb 没效果——在线设备要改各自的 bdi 文件，全局 sysctl 只管以后新出现的设备。误区二：认为 DONTNEED 万能——它对脏页无效，回写完成前页依然占着内存。误区三：预读窗口越大越好——随机负载下大窗口等于放大浪费，还可能把热数据挤出缓存。误区四：预读能救慢盘——它只是摊薄每次等待的固定开销，介质本身的物理极限它无能为力，盘该换还得换。误区五：mmap 大文件顺序扫描慢就怪预读——mmap 路径的窗口语义不同，先确认缺页行为再下结论。

容器环境还有一层映射关系要说清：容器共享宿主机内核，块设备 bdi 是宿主机全局资源，容器里改预读参数通常要落到宿主侧执行；overlayfs 上的文件冷读要穿透多层查找，预读窗口的收益会被层间开销略稀释，重 IO 容器建议把数据卷直挂宿主目录或独立块设备。观测同理，块层跟踪工具要在宿主机上看，容器内看到的只是文件系统层的影子。把「参数在哪一层生效、观测在哪一层做」想清楚，容器里的预读调优就不会白忙。

小结

预读是页缓存读路径的自适应启发式：顺序命中就指数扩张窗口，乱序跳读就收缩回小窗口，用最小的赌注换取顺序吞吐的数量级提升。它的两个盲区——双流交错与 mmap 读路径——提醒我们启发式会误判，而 posix_fadvise 正是应用纠正误判的官方通道。

落地时记住三个动作：先识别负载形态，再决定是否调整窗口；顺序流量用 SEQUENTIAL、WILLNEED 与 DONTNEED 组成「预热、加速、释放」三件套；备份与迁移工具务必防缓存自污染。系统层参数分清全局默认与在线设备的 bdi，改完用 iostat 与 biosnoop 验证单次 IO 尺寸是否如预期变大。

预读的本质是时间与空间的权衡：用可能的浪费换确定的吞吐。理解这一点，就不会再被「顺序读为什么只有随机读三倍快」这类问题困住——答案通常就写在窗口大小里。