2-PageCachechan产生释放及优化( 六 ) _回收

其中 CPU0～11，24～35 的 local node 为 node 0；而 CPU12～23，36～47 的 local node 为 node 1
推荐将配置为 0 。
$ echo 0 > /proc/sys/vm/zone_reclaim_modevm.zone_reclaim_mode = 0
相比内存回收的危害而言，NUMA 带来的性能提升几乎可以忽略，所以配置为 0，利远大于弊。
*直接内存回收引起 load飙高时，就去调整内存水位设置；脏页积压引起 load 飙高时，就需要去调整脏页的水位； NUMA 策略配置不当引起 load 飙高时，就去检查是否需要关闭该策略。同时我们在做这些调整的时候，一定要边调整边观察业务的服务质量，确保 SLA 是可以接受的。*
Page Cache 太容易回收而引起的问题
这类问题做个总结，大致可以分为两方面：
误操作而导致 Page Cache 被回收掉，进而导致业务性能下降明显；
内核的一些机制导致业务 Page Cache 被回收，从而引起性能下降。
对 Page Cache 操作不当产生的业务性能下降
对于 Page Cache 而言，是可以通过来清掉的(echo 3 > /proc/sys/vm/) 但是这样做是会有一些负面影响的，比如说这些 Page Cache 被清理掉后可能会引起系统性能下降
其实这和 inode 有关，inode 是内存中对磁盘文件的索引，进程在查找或者读取文件时就是通过 inode 来进行操作的
进程会通过 inode 来找到文件的地址空间（），然后结合文件偏移（会转换成 page index）来找具体的 Page 。如果该 Page 存在，那就说明文件内容已经被读取到了内存；如果该 Page 不存在那就说明不在内存中，需要到磁盘中去读取。
来释放 inode 的话，应该会清楚它有几个控制选项，我们可以通过写入不同的数值来释放不同类型的 cache（用户数据 Page Cache，内核数据 Slab，或者二者都释放
当我们执行 echo 2 来 drop slab 的时候，它也会把 Page Cache 给 drop 掉
由于是一种内存事件，内核会在 /proc/ 中来记录这一事件，所以我们可以通过 /proc/ 来判断是否有执行过
$ grep drop /proc/vmstatdrop_pagecache 3drop_slab 2
如上所示，它们分别意味着被 drop 了 3 次（通过 echo 1 或者 echo 3），slab 被 drop 了 2 次（通过 echo 2 或者 echo 3）。如果这两个值在问题发生前后没有变化，那就可以排除是有人执行了；否则可以认为是因为引起的Page Cache 被回收。
内核机制引起 Page Cache 被回收而产生的业务性能下降
在内存紧张的时候会触发内存回收，内存回收会尝试去回收（可以被回收的）内存，这部分内存既包含 Page Cache 又包含(比如 slab) 。我们可以用下图来简单描述这个过程：
是指回收者，它可以是内核线程（包括）也可以是用户线程。回收的时候，它会依次来扫描page 和 slab page 中有哪些可以被回收的，如果有的话就会尝试去回收，如果没有的话就跳过。
inode 被回收的话，那么它对应的 Page Cache 也都会被回收掉，所以如果业务进程读取的文件对应的 inode 被回收了，那么该文件所有的 Page Cache 都会被释放掉，这也是容易引起性能问题的地方
可以通过 /proc/ 来观察
$ grep inodesteal /proc/vmstatpginodesteal 114341kswapd_inodesteal 1291853
这个行为对应的事件是，就是上面这两个事件，
其中是指在回收的过程中，因为回收 inode 而释放的page 个数；是指之外其他线程在回收过程中，因为回收 inode 而释放的 page 个数。
所以在你发现业务的 Page Cache 被释放掉后，你可以通过观察来发现是否因为该事件导致的
如何避免 Page Cache 被回收而引起的性能问题