2-PageCachechan产生释放及优化

2-PageCache生产释放及优化

观察PageCache

page cache，又称pcache，其中文名称为页高速缓冲存储器 页缓存

Page Cache 有关的场景 故障场景

服务器的 load 飙高； 服务器的 I/O 吞吐飙高； 业务响应时延出现大的毛刺； 业务平均访问时延明显增加。

Page Cache 管理不当除了会增加系统 I/O 吞吐外，还会引起业务性能抖动 本文用数据剖析什么是 Page Cache，为什么需要 Page Cache，Page Cache 的产生和回收是什么样的

​ 应用程序产生Page Cache的逻辑示意图

红色的地方就是 Page Cache，很明显，Page Cache是内核管理的内存，也就是说，它属于内核不属于用户

在 Linux 上直接查看 Page Cache 的方式有很多，包括 /proc/meminfo、free 、/proc/vmstat 命令等

/proc/meminfo 模式查看

$ cat /proc/meminfo
...
Buffers: 1224 kB
Cached: 111472 kB
SwapCached: 36364 kB
Active: 6224232 kB
Inactive: 979432 kB
Active(anon): 6173036 kB
Inactive(anon): 927932 kB
Active(file): 51196 kB
Inactive(file): 51500 kB
...
Shmem: 10000 kB
...
SReclaimable: 43532 kB

Buffers + Cached + SwapCached  =  Active(file) + Inactive(file) + Shmem +SwapCached

那么等式两边的内容就是我们平时说的 Page Cache 两边都是SwapCached

等式右边这些项把 Buffers 和 Cached 做了一下细分，分为了 Active(file)，Inactive(file) 和 Shmem

Buffers 更加依赖于内核实现

等式右边和应用程序的关系更加直接

在 Page Cache 中，Active(file)+Inactive(file) 是 File-backed page（与文件对应的内存页），是你最需要关注的部分。因为你平时用的 mmap() 内存映射方式和 buffered I/O来消耗的内存就属于这部分，最重要的是，这部分在真实的生产环境上也最容易产生问题，我们在接下来的课程案例篇会重点分析它

SwapCached 是在打开了 Swap 分区后，把 Inactive(anon)+Active(anon) 这两项里的匿名页给交换到磁盘（swap out），然后再读入到内存（swap in）后分配的内存。由于读入到内存后原来的 Swap File 还在，所以 SwapCached 也可以认为是 File-backedpage，即属于 Page Cache。这样做的目的也是为了减少 I/O。

SwapCached 只在 Swap 分区打开的情况下才会有，而我建议你在生产环境中关闭Swap 分区，因为 Swap 过程产生的 I/O 会很容易引起性能抖动。

除了 SwapCached，Page Cache 中的 Shmem 是指匿名共享映射这种方式分配的内存（free 命令中 shared 这一项），比如 tmpfs（临时文件系统），这部分在真实的生产环境中*产生的问题比较少 * 本专栏不做介绍

free 命令中的 buff/cache 究竟是指什么呢？我们在这里先简单地看一下：

$ free -k
total used free shared buff/cache availabl
Mem: 7926580 7277960 492392 10000 156228 43068
Swap: 8224764 380748 7844016

通过 procfs 源码里面的proc/sysinfo.c这个文件，你可以发现 buff/cache 包括下面这几项：

buff/cache = Buffers + Cached + SReclaimable

前面的数据我们也可以验证这个公式: 1224 + 111472 + 43532 的和是 156228

这些数据是动态变化的，而且执行命令本身也会带来内存开销，所以这个等式未必会严格相等

从这个公式中，你能看到 free 命令中的 buff/cache 是由 Buffers、Cached 和SReclaimable 这三项组成的，它强调的是内存的可回收性，也就是说，可以被回收的内存会统计在这一项。

其中 SReclaimable 是指可以被回收的内核内存，包括 dentry 和 inode 等。而这部分内容是内核非常细节性的东西， 本章不做介绍。

掌握了 Page Cache 具体由哪些部分构成之后，在它引发一些问题时，你就能够知道需要去观察什么。比如说，应用本身消耗内存（RSS）不多的情况下，整个系统的内存使用率还是很高，那不妨去排查下是不是 Shmem(共享内存) 消耗了太多内存导致的

如果不用内核管理的 Page Cache，那有两种思路来进行处理：

第一种，应用程序维护自己的 Cache 做更加细粒度的控制，比如 MySQL 就是这样做 的，你可以参考MySQL Buffer Pool 实现自己的 Cache 成本还是挺高的，不如内核的 Page Cache 来得简单高效

第二种，直接使用 Direct I/O（直接读写） 来绕过 Page Cache，不使用 Cache 了

下面举例为什么需要PageCache

标准 I/O 和内存映射会先把数据写入到 PageCache，这样做会通过减少 I/O 次数来提升读写效率。我们看一个具体的例子。首先，我们来生成一个 1G 大小的新文件，然后把 Page Cache 清空，确保文件内容不在内存中， 以此来比较第一次读文件和第二次读文件耗时的差异。具体的流程如下

先成一个 1G 的文件：

ddif = /dev/zeroof = /home/yafang/test/dd.outbs = 4096count =((1024*256))

其次，清空 Page Cache，需要先执行一下 sync 来将脏页（第二节课，我会解释一下什么是脏页）同步到磁盘再去 drop cache

$ sync && echo 3 > /proc/sys/vm/drop_caches

第一次读取文件的耗时如下：

$ time cat /home/yafang/test/dd.out &> /dev/null
real 0m5.733s
user 0m0.003s
sys 0m0.213s

再次读取文件的耗时如下：

$ time cat /home/yafang/test/dd.out &> /dev/null
real 0m0.132s
user 0m0.001s
sys 0m0.130s

通过这样详细的过程你可以看到，第二次读取文件的耗时远小于第一次的耗时ÿ