对Page Cache操作不当产生的业务性能下降

Posted 2022-09-13 公众号JavaEdge

Page Cache太易回收而导致的问题，大致可分为：

• 误操作，导致Page Cache被回收，进而导致业务性能下降明显
• 内核的一些机制导致业务Page Cache被回收，从而引起性能下降

若业务数据对延迟敏感或你的业务指标对TP99（99分位）要求较高，你更需要关注这些问题。

言归正传，我们来看下发生在生产环境中的案例。

1 对Page Cache操作不当产生的业务性能下降

分析误操作导致Page Cache被回收掉的情况，是怎样发生的。

Page Cache可以通过drop_cache清掉，很多人在看到系统存在很多Page Cache时，会习惯使用drop_cache清理，但这样做有一些负面影响，比如说这些Page Cache被清理掉后可能会引起系统性能下降。这和inode有关。

1.1 inode

内存中对磁盘文件的索引，进程在查找或读取文件时，就是通过inode操作：

如上图，进程会通过inode来找到文件的地址空间（address_space），然后结合文件偏移（会转换成page index）找具体Page：

• 若该Page存在，则说明文件内容已被读取到内存
• 若该Page不存在，则说明不在内存，需到磁盘读取

可以理解inode是Pagecache Page（页缓存的页）的宿主（host），若inode不存在，则PageCache Page也就不存在。

若使用过drop_cache释放inode，它有几个控制选项，可通过写入不同的数值来释放不同类型的cache（用户数据Page Cache，内核数据Slab或都释放）：

于是这就引入易忽略问题：执行echo 2来drop slab时，它也会把Page Cache给drop掉。

在系统内存紧张时，会想通过drop_caches释放一些内存，但由于清楚Page Cache被释放掉会影响业务性能，所以就期望只去drop slab而不去drop pagecache。于是很多人就运行 echo 2 > /proc/sys/vm/drop_caches，但结果出乎意料：Page Cache也被释放，业务性能产生明显下降。

系统正运行着，忽然Page Cache被释放，由于不清楚释放原因，很多人就怀疑，是不是由其他人/程序执行drop_caches导致。如何观察这个inode释放引起Page Cache被释放的行为呢？

如何观察是否有人或者有程序执行过drop_caches？

drop_caches是一种内存事件，内核会在/proc/vmstat中来记录这一事件，所以可通过/proc/vmstat判断是否执行过drop_caches。

$ grep drop /proc/vmstat
# pagecache被drop了3次（通过echo 1 或者echo 3）
drop_pagecache 3
# slab被drop了2次（通过echo 2或者echo 3）
drop_slab 2

若这俩值在问题发生前后没有变化，就能排除是有人执行了drop_caches；否则能认为是因为drop_caches引起的Page Cache被回收。

除了在执行drop cache前三思而后行，还有其他根治方案。