linux pagecache限制与查看

原文链接：http://www.cnblogs.com/10087622blog/p/8191169.html

以前也有一些疑问，发现hadoop 缓存用的很多，而我们运维当作未使用，要减少内存，我们查了一些资料，详细了解了hadop 中 缓存的使用，发现这个资料不错，就自己收藏起来。在linux服务器使用过程中，由于linux对内存的使用原则是能cache就尽量cache，所以会出现pagecache占用很多的情况。

suse的版本有一个pagecachelimit的功能，centos中没有看到。即便是将这个功能合入到centos中，也会发现设置了没效果的情况。

cat /proc/sys/vm/pagecache_limit_mb 
0

1.将0改为对应的值，比如说12000，限制为120G，我们来看对应的内核中算法为什么没有生效，

page cache总数 ＞ 8*free_pages + pagecache_limit_mb

算法的关键是判断是否需要进行pagecache限制触发的回收，当pagecache设置某个值之后，系统中并不是直接以这个值作为判断标志，而是加上了free的限制，

从这个意义上说，因为设置的pagecache_limit_mb比较少，但是当free很多的时候，是比较难触发这个条件的。那么要加大回收还有哪些手段？下面针对读和写两个方面来描述。

2.是通过修改/proc/sys/vm/dirty_background_ration以及/proc/sys/vm/dirty_ratio两个参数的大小来实现回收。

这种场景针对的是很多写的情况：vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外设；

vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。

为什么需要两个比例？之前一直错误的认为dirty_ratio的触发条件不可能达到，因为每次肯定会先达到vm.dirty_background_ratio的条件，后来根据业务现象，发现不是如此。确实是先达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作，但是这一过程中应用进程仍然可以进行写操作，如果多个应用进程写入的量大于flush进程刷出的量那自然有可能达到vm.dirty_ratio这个参数所设定的坎，此时操作系统会转入同步地处理脏页的过程，可能阻塞应用进程。

3.针对流媒体使用的时候，写脏页不多，大多数是读的场景，大多是sendfile或者read引起了很多文件进入cache，但是这些文件被继续访问的概率很低，所以相当于是一次性使用，之后相当长的时间之内是不会再使用的，所以我们对于pagecache限制的需求很强烈，由于内核本身就有根据水线来动态回收page cache的功能，因此问题的根源可能还在于默认情况下min和low水线间隔太近，导致当free内存低于low水线后，发起的kswapd回收太慢，无法跟上临时大量内存申请的节奏，从而free内存很快突破min水线，造成内存申请过程中进行cache回收或是申请失败，从而引起性能问题

因此解决问题的办法之一，可以通过加大min和low水线之间的间隔来实现

内核刚好提供了这样一个参数，即/proc/sys/vm/extra_free_kbytes，设置该参数后将拉大min和low水线的间隔，从而保证有足够的空闲内存来应对临时大量的内存动态申请。

4.加大水线，提高水线有助于提前触发回收，这样相当于后面的内存需求，能从时间上更快触发回收，但是当你的内存消耗速度大于内存回收的速度，还是会cahce很多，kswap很高。

5.如果还是回收不及时的话，那么需要将kswap的nice级别调低，也有一些帮助，renice设置为-20，虽然从调度上来说它还是低于实时进程，但是比调整前级别高了些。

6.使用posix_madvise，madvise，fadvise，利用POSIX_MADV_DONTNEED特性，但也不能调用太多，容易引起sys冲高，大家在测试的时候，可以分别对访问几M之后做清理，找到最佳的设置点。

7.修改系统调用，带入一个特性值进入，使得系统得知不放入cache，这个和directio的区别是，尽量不要拷贝到用户态，要区分应用场景，因为directio目前还不支持sendfile这种调用，需要多一次拷贝，也就是虽然节省了查找address_space中的radix树的流程，但是多了一次内核到用户态的内存拷贝。当然，我曾经尝试将directio变成支持sendfile，因为sendfile是基于splice的调用，而原来的directio的流程中，是将用户的页面作为写入地址的，所以需要将directio中对页面的检查部分进行定制修改，主要修改pmd的映射。

8.如果是内存化的存储介质，也就是可以按字节寻址的存储介质，则可以开启DAX特性，mount挂载的时候，带上该特性，这样就绕过了pagecache。

9.这个是对6的改进，有一定的特殊性，在加入radix树之前，主动调用 invalidate_mapping_pages ，这个比在用户态释放麻烦些，但是效果更好。

 

 如果大家有更好的办法，希望能提醒一下我。

另外，cache里面保持了哪些内容，这个问题经常会被问到。

这里要提到两个工具，一个是vmtouch，另外一个是hcache，源码我就不贴了，有兴趣的可以去网上下载。

lsof |grep REG|grep mnt|sort -u |awk '{print $9}'|xargs vmtouch

这个会将我们应用场景下cache占用的文件累计起来，大家要使用的话需要根据文件名称过滤一下。前提是这个文件的句柄还在被pid所持有，有的文件fd已经关闭，但是还是在系统中存放，那么这个方法是获取不到的。

除了这两个工具查看，还有slab的占用要算在里面，

SlabInfo=`cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'`

 

常见的还有另外一个问题，就是热点文件的访问，当时我的处理思路是，每隔一段时间，取一下lsof，然后对比前后两个文件。

#!/bin/bash

sum=0;

while read line
do
  if [ $(grep $line $2|wc -l) -eq 1 ]
  then
    echo $line >>$1_2_$2.txt
    sum=$(($sum+1))
  fi
done < $1
 echo "sum=$sum"

sum的个数就是前后相同的文件个数，不太精确，因为文件有打开就有关闭，但是多次取样的话，效果还可以。

 

有的应用场景会尽量不要pagecache，比如视频点播，但是又不能用dio读，因为dio读有对齐要求，而且没法预读，常用的办法是在用户态取dropcache，但这个dropcache不分青红皂白，

所以我们在内核态改造成了对某些特定格式，特定大小，特定访问时间的进行drop，效果比较好。