Linux的cached和pagecache清除 解决缓存、内存不足、测试结果影响问题

最近做的一个NLP文本处理组件的项目中用到了apache的Lucene，在后来的性能测试过程中，关键词、相似文章推荐功能的性能指标应该随着文章数量（索引规模）的增大而下降，但是在拿到的测试数据中，却正好相反。非常费解。后来才悟道是Linux下缓存了一定的Lucene index，导致后读取的反而比之前读取的更快，影响了测试的准确度（或者说是因为没有控制好测试的变量，忽略了缓存对索引读写的影响）。

有时候用free -m看一下发现内存使用量竟然特别的高。

现在开始在Linux中设置一下，将内存中的各种cache及时清理。

命令：

    sync

    echo 3 >/proc/sys/vm/drop_caches

只有这两行。

第一行：是强制将内存中内容写入硬盘，包含已修改的 i-node、已延迟的块 I/O 和读写映射文件。这一步是确保第二步的安全性。防止数据或操作丢失。

第二行：

先看看官方的说法：

/proc/sys/vm/drop_caches (since Linux 2.6.16) 
Writing to this file causes the kernel to drop clean caches,
dentries and inodes from memory, causing that memory to become
free.

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to
free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
to free pagecache, dentries and inodes, use echo 3 >
/proc/sys/vm/drop_caches.

Because this is a non-destructive operation and dirty objects
are not freeable, the user should run sync first.

看来只有内核在2.6.16以上的才支持。

而且之前的sync挺重要。

运行前可以先查看一下： cat /proc/sys/vm/drop_caches 发现默认为0。

网上看到有人这么分析，觉着挺有理 mark过来：

很多用户对Linux内存管理方面的疑问，这个办法给出了一个比较“直观”的回复，我更觉得有点像是核心开发小组的妥协。

对于是否需要使用这个值，或向用户提及这个值，我是有保留意见的：

1、从man可以看到，这值从2.6.16以后的核心版本才提供，也就是老版的操作系统，如红旗DC 5.0、RHEL 4.x之前的版本都没有；
2、若对于系统内存是否够用的观察，我还是原意去看swap的使用率和si/so两个值的大小；

    用户常见的疑问是，为什么free这么小，是否关闭应用后内存没有释放？

    但实际上，我们都知道这是因为Linux对内存的管理与Windows不同，free小并不是说内存不够用了，应该看的是free的第二行最后一个值：

-/+ buffers/cache: 58 191

这才是系统可用的内存大小。

    实际项目中告诉我们，如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？

    所以说，我觉得既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因。如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

    我觉得，排除内存不足的情况外，除非是在软件开发阶段，需要临时清掉buffer，以判断应用的内存使用情况；或应用已经不再提供支持，即使应用对内存的 时候确实有问题，而且无法避免的情况下，才考虑定时清空buffer。（可惜，这样的应用通常都是运行在老的操作系统版本上，上面的操作也解决不了）。