事情是这样的，前几日由于拷贝过数据库的全备份到测试服务器，导致使用free命令时发现内存的free可用占用非常小，buff/cache占用的非常大，本来是想用如下命令进行内存释放的，后来通过一番查询后发现buff/cache是不需要清理的。

sync：先执行这个，是用来将系统中未提交的事务存在磁盘中
echo 1 > /proc/sys/vm/drop_caches:表示清除pagecache。
echo 2 > /proc/sys/vm/drop_caches:表示清除回收slab分配器中的对象（包括目录项缓存和inode缓存）。slab分配器是内核中管理内存的一种机制，其中很多缓存数据实现都是用的pagecache。
echo 3 > /proc/sys/vm/drop_caches:表示清除pagecache和slab分配器中的缓存对象。
sync

原因：
1、从man可以看到，这值从2.6.16以后的核心版本才提供，也就是老版的操作系统，如红旗DC 5.0、RHEL 4.x之前的版
本都没有；
2、若对于系统内存是否够用的观察，我还是原意去看swap的使用率和si/so两个值的大小； 用户常见的疑问是，为什么free这么小，是否关闭应用后内存没有释放？ 但实际上，我们都知道这是因为Linux对内存的管理与Windows不同，free小并不是说内存不够用了，应该看的是free的第二行最后一个值： available 这才是系统可用的内存大小。 实际项目中告诉我们，如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比
较难查看。 相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？ 所以说，我觉得既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。 一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。 当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

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

3、完全没必要这么做，即使内存全被cache满了，运行一个大程序，绝不会存在“内存不足”的情况，需要多少内存系统就会从cacahe释放出来多少的，cache的好处是可以减小很多磁盘访问。
清理效果演示：
首先执行free -g 查看内存使用情况

然后执行清楚缓存命令效果如图