清理buff/cache，释放更多的cache，让free大一点

那么 buff/cache主要是来干嘛的呢？

Linux具有先进的缓存机制，会针对会针对dentry(用于VFS，加速文件路径名到inode的转换)、Buffer Cache(针对磁盘块的读     写)和Page Cache(针对文件inode的读写)进行缓存操作用来提高读写效率。但是在进行了大量文件操作之后，缓存会把内存资源基本用光,虽然文件读取效率提高了，但是物理内存会逐渐被吃光。那么为什么操作系统不会主动回收呢，原来是因为drop_caches的默认参数设置的就是不释放的，

清理前

# !/bin/bash 
# clean buff/cache
# author: hobby

echo "Start cleaning buff/cache"

# 将所有未写的系统缓冲区写到磁盘中
sudo sync;sync;sync   
#延迟5秒
sleep 5  
# 释放页缓存
sudo echo 1 > /proc/sys/vm/drop_caches
# 释放dentries和inodes
sudo echo 2 > /proc/sys/vm/drop_caches
# 释放所有缓存
sudo echo 3 > /proc/sys/vm/drop_caches

echo "cleaning ending......"

清理后

效果还是有的

在某位博主那看到下面三段话，觉得十分有理（附上来源https://www.jianshu.com/p/016f7cf0380d）

       如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。

       一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

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