Linux Page Cache 详解

你一定遇到过这样的场景：
第一次打开一个几个 G 的大日志文件，要等好几秒才能加载完；
关掉再重新打开，瞬间就出来了；
甚至你用 dd 测磁盘速度，第一次跑是 300MB/s，第二次跑直接跑到了 8GB/s，快了几十倍。

这到底是为什么？磁盘的速度什么时候变得这么快了？

其实，这不是磁盘变快了，是 Linux 偷偷在背后帮你做了缓存 —— 这就是 Page Cache（页缓存），Linux 系统里最被低估的性能神器。

用一个仓库的比喻，秒懂 Page Cache

我们把整个系统比作一个电商仓库：

• • 磁盘：就是仓库的大货架，放着所有的商品，但是它离前台很远，你要取货的话，得开车跑很远，来回要好几分钟；
• • 内存：就是前台的小货架，离你很近，伸手就能拿到，但是空间有限，放不下所有的商品。

Page Cache 是什么？就是前台的这个小货架。

当你第一次要拿一个商品的时候，你没办法，只能开车去大仓库取，花了好几分钟；
但是取回来之后，你不会把它直接给客户就完事了，你会顺便把它放到前台的小货架上 —— 因为你觉得，客户大概率很快还要再要这个东西。
果然，第二次客户要这个商品的时候，你不用再跑大仓库了，直接从前面的小货架拿，一秒钟就搞定了。

这就是 Page Cache 的全部逻辑：Linux 把你读过的文件内容，偷偷缓存到内存里，下次你再读的时候，直接从内存拿，不用再去读慢的磁盘了。

Page Cache 到底是怎么工作的？

我们来拆解一下，当你调用 read\(\) 读一个文件的时候，内核到底做了什么：

1. 先查缓存：有没有？

当你要读文件的某一块内容时，内核第一步不是直接去读磁盘，而是先去 Page Cache 里查：

哎，这块内容我之前是不是读过？是不是已经在内存里了？

如果找到了，这就叫「缓存命中」，内核直接把内存里的数据拷贝给你，整个过程不到 1 毫秒，比读磁盘快几百倍。

2. 没命中？去读磁盘，然后存起来

如果没找到，这就叫「缓存 miss」，内核没办法，只能去磁盘读数据。

但是读完之后，内核不会只把你要的那点数据给你就完事了，它会把这块数据存到 Page Cache 里，这样下次你再读的时候，就能直接用了。

3. 更聪明的：预读！

内核比你想的更聪明，它知道：大部分时候，你读文件都是顺序读的 —— 比如你读了前 1024 字节，接下来大概率要读后面的 1024 字节。

所以，当你读前 1024 字节的时候，内核会顺便把后面的 128KB（默认的预读窗口）都一起读进 Page Cache 里！

这就是为什么你读大文件的时候，越读越快：

• • 第一块，你等了磁盘的延迟，读进来；
• • 后面的所有块，内核早就预读到缓存里了，你直接拿就行，根本不用等磁盘。

这也是为什么顺序读的性能，能比随机读快那么多 —— 预读把顺序读的所有 IO 都提前缓存了，相当于全程在读内存。

为什么第二次读，快了几十倍？

现在你就懂了，为什么同一个文件，第一次读和第二次读，速度差了几十倍：

我们来做个真实的测试，你自己也可以在服务器上跑一下：

# 先创建一个 1GB 的测试文件
ddif=/dev/zero of=test.bin bs=1M count=1024

# 第一次读，清空缓存，模拟第一次读
echo 3 > /proc/sys/vm/drop_caches
timeddif=test.bin of=/dev/null bs=1M

第一次的结果大概是这样：

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.12 s, 344 MB/s

real    0m3.125s
user    0m0.012s
sys     0m0.876s

这是磁盘的真实速度，普通的 SATA SSD 大概就是 300-500MB/s，NVMe 能到 3GB/s 左右。

然后我们第二次读，不清空缓存：

timeddif=test.bin of=/dev/null bs=1M

结果直接变了：

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.12 s, 8.7 GB/s

real    0m0.125s
user    0m0.008s
sys     0m0.117s

速度直接跑到了 8GB/s，这就是内存的速度！因为这时候，数据已经在 Page Cache 里了，根本没碰磁盘。

这就是你遇到的「文件越读越快」的真相：不是磁盘变快了，是你第二次读的根本不是磁盘，是内存。

内存不够了怎么办？缓存会被淘汰吗？

很多人会问：内存就这么大，我读了很多大文件，缓存把内存占满了怎么办？

别担心，Linux 早就想好了：

1. 1. Page Cache 只会用空闲的内存：内核会把你没用的空闲内存，都拿来做缓存，反正闲着也是闲着，用来提升性能不好吗？
2. 2. LRU 淘汰机制：当内存真的不够用了，内核会把那些很久都没用到的缓存页淘汰掉，腾出空间给新的内容。这个机制叫 LRU（最近最少使用），简单来说就是：谁最久没被用过，谁就先被淘汰。
3. 3. 缓存是可回收的：和进程自己的内存不一样，Page Cache 占用的内存，是可以随时回收的。当有新的进程需要内存的时候，内核会直接把缓存的内存释放出来，给进程用，完全不会影响进程的运行。

这就是为什么你用 free 命令看，经常会看到 buff/cache 占了很多内存，而 free 空闲内存很少：

total        used        free      shared  buff/cache   available
Mem:        16096588    2345678     1234567      123456    12518353    13456789

很多新手看到这个会慌：“我的内存是不是被占满了？”
其实不是的，available 那一行才是你真正可用的内存，它已经把可以回收的缓存算进去了。只要你不是把 available 用完，就完全不用担心内存不够。

写的时候，Page Cache 也在帮你

你以为 Page Cache 只帮读？不对，写的时候它也在偷偷优化。

当你调用 write\(\) 写文件的时候，内核不会立刻把数据写到磁盘，而是：

1. 1. 先把数据写到 Page Cache 里，标记为「脏页」（就是和磁盘上的数据不一样的页）；
2. 2. 然后立刻返回给你，告诉你 “写好了”，不用等磁盘的慢 IO；
3. 3. 内核后台有一个 flusher 线程，会定期把脏页刷到磁盘上，而且会把很多小的写操作合并成一个大的 IO，大大提升写的性能。

这就是为什么你写大文件的时候，一开始能跑到几百 MB/s，后来会变慢：一开始都是写缓存，很快，等缓存满了，就要等磁盘刷了，速度就降到磁盘的真实速度了。

不过要注意，脏页如果还没刷到磁盘，这时候机器掉电了，数据就会丢。所以像数据库这种对数据安全要求高的软件，会调用 fsync\(\) 强制把脏页刷到磁盘，保证数据真的写到磁盘上了，才会返回。

这些误区，你一定要避开

1. Buffer Cache 和 Page Cache 是一回事吗？

很多人会搞混这两个，以前老的 Linux 里，它们是分开的：

• • Buffer Cache：用来缓存块设备的原始数据；
• • Page Cache：用来缓存文件的内容。

但是从 Linux 2.6 之后，它们就合并了，现在你看到的 buff/cache，其实就是这两个的总和，不用再区分它们了，本质上都是内存缓存。

2. Page Cache 是每个进程自己的？

不对！Page Cache 是内核管理的，所有进程共享的！
比如 A 进程读了一个文件，把内容缓存到 Page Cache 里，B 进程再读这个文件，也能命中缓存，不用再读磁盘。这就是为什么很多时候，多个进程读同一个文件，性能会好很多，因为缓存是共享的。

3. 清空缓存会伤磁盘吗？

很多人会用 echo 3 \> /proc/sys/vm/drop\_caches 来清空缓存，比如测试磁盘性能的时候，怕缓存影响结果。
这个操作是完全安全的，它只是把缓存的内容清掉，不会动磁盘上的数据，也不会伤磁盘，放心用就行。

4. 为什么数据库要用 Direct IO？

因为数据库自己已经做了缓存了，比如 MySQL 的 Buffer Pool，它自己把热点数据缓存到内存里了。如果这时候还用内核的 Page Cache，就等于缓存了两次，浪费内存，还多了一次拷贝的开销。
所以数据库会用 Direct IO，绕过 Page Cache，直接读写磁盘，自己管理缓存。

最后：Page Cache 是 Linux 的性能魔法

Page Cache 是 Linux 里最基础，也最强大的性能优化手段。它把慢的、随机的磁盘 IO，变成了快的、内存的 IO，让整个系统的性能提升了一个量级。

你平时用电脑、用服务器，大部分时候的快，都有它的功劳：

• • 你打开文件的速度，
• • 你编译代码的速度，
• • 你访问网页的速度，
  背后都有 Page Cache 在偷偷帮你缓存数据，让你觉得 “一切都很快”。

这就是为什么，Linux 会把所有空闲的内存都拿来做缓存 —— 内存不用来做缓存，难道用来闲着吗？