为什么要在Linux中删除caching?

在我们的服务器中,我们有一个在午夜放弃caching的习惯。

sync; echo 3 > /proc/sys/vm/drop_caches 

当我运行代码似乎释放大量的内存,但我真的需要这样做。 RAM不是免费的吗?

    你100%正确。 释放RAM 不是一个好习惯。 这可能是货物邪教系统pipe理的一个例子。

    是的,清除caching将释放RAM,但会导致内核在磁盘上而不是在caching中查找可能导致性能问题的文件。

    通常,内核将在可用RAM耗尽时清除caching。 它经常使用pdflush将变脏的内容写入磁盘。

    像这样丢弃caching的原因是为了对磁盘性能进行基准testing,并且是存在的唯一原因。

    在运行I / O密集型基准testing时,您需要确保您尝试的各种设置实际上都是在进行磁盘I / O,因此Linux允许您删除caching而不是完全重新启动。

    从文档引用:

    这个文件不是控制各种内核caching(inode,dentries,pagecache等等)增长的手段。当系统中的其他地方需要内存时,内核会自动回收这些对象。

    使用此文件可能会导致性能问题。 由于它放弃了caching的对象,因此可能会花费大量的I / O和CPU来重新创build被删除的对象,特别是在被大量使用的情况下。 因此,build议不要在testing或debugging环境之外使用。

    这里的基本思想可能不是那么糟糕(只是非常天真和误导):可能有文件被caching,在不久的将来不太可能被访问,例如日志文件。 这些“吃东西”的内存,稍后必须在必要时由操作系统以某种方式释放。

    根据您的swappiness,文件访问模式,内存分配模式以及更多不可预知的事情的设置,可能会发生这样的情况:当您不释放这些caching时,它们将被强制重新使用,这需要比从未使用的内存池中分配内存。 在最坏的情况下,linux的swappiness设置会导致程序存储器被换出,因为linux认为这些文件在不久的将来可能比程序存储器更有可能被使用。

    在我的环境中,linux经常会猜错,在大多数欧洲股票交易所(大约在当地时间09:00)开始的时候,服务器将开始做每天只做一次的事情,需要交换先前被交换出来的内存,因为写日志文件,压缩它们,复制它们等等,都将caching填满,以至于事物必须被交换出去。

    但是,正在放弃caching解决这个问题? 肯定不是。 这里的解决办法是告诉linux不知道什么:这些文件可能不会再被使用。 这可以通过使用诸如posix_fadvise()类的写入应用程序来完成,或者使用诸如vmtouch类的cmd行工具(其也可以用于查看事物以及caching文件)来完成。

    这样你就可以从caching中删除不再需要的数据,并保留应该caching的内容,因为当你删除所有的caching时,很多东西必须从磁盘上重新读取。 而在最糟糕的时刻:何时需要; 导致您的应用程序延迟显着,往往是不可接受的。

    你应该有一个系统,监控你的内存使用模式(例如,如果是交换),然后进行相应的分析,并采取相应的行动。 解决办法可能是使用vtouch在一天结束时驱逐一些大文件; 也可能是增加更多内存,因为服务器的每日高峰使用率就是这样。

    我已经看到,在启动一堆虚拟机时,放置caching很有用。 或其他任何使用大页面的数据库服务器。

    Linux中的大页面通常需要对RAM进行碎片整理,以find2MB的连续物理RAM放入页面。 释放所有的文件caching使得这个过程非常简单。

    但我同意大多数其他答案,因为没有一个通常很好的理由每晚放弃文件caching。

    如果没有具备技能或经验的人真正发现问题,那么这可能是为了稳定系统。

    释放资源

    删除caching将从本质上释放一些资源,但是这有一个副作用,使系统实际上更难做它正在做的事情。 如果系统正在交换(试图从磁盘交换分区读取和写入比实际能力更快的速度),那么定期删除caching可以缓解症状 ,但是无法解决问题。

    什么是吃掉记忆?

    你应该确定是什么导致大量的内存消耗,使得caching似乎工作。 这可能是由于任何数量的configuration不当或者仅仅是错误使用的服务器进程造成的。 例如,在一台服务器上,当Magento网站在15分钟内达到一定数量的访问者时,我目睹了内存利用率的最大值。 最终导致Apache被configuration为允许太多进程同时运行。 太多的进程,使用大量的内存(Magento有时是一个野兽)=交换。

    底线

    不要以为这是必要的。 要主动找出为什么它存在,如果别人认为它是错误的,有胆量禁用它,并观察系统 – 了解真正的问题是什么,并解决它。

    Linux / m68k实际上有一个内核错误,导致kswapd疯狂并占用100%的CPU(如果还有一些其他的CPU绑定任务,比如Debian二进制包autobuilder – vulgo buildd – 已经运行了),可以(大多数的时间;并非总是)每隔几个小时运行一次这个特定的命令就能减轻。

    这就是说…你的服务器很可能不是一个m68k(Atari,Amiga,经典的Macintosh,VME,Q40 / Q60,Sun3)系统;-)

    在这种情况下,排队的人要么跟随一些有问题的,要么是过时的build议,或者得到关于如何使用RAM的想法(现代的想法确实是说“免费的RAM是RAM浪费的”,并build议caching) ,或者“发现”这个“修复”了另一个问题(并且懒得去寻找适当的修复)。

    其中一个原因可能是该网站正在运行某种监控,检查免费ram的数量,并在免费ram降到一定比例以下时向pipe理员发送警告。 如果这个监控工具足够笨,不能在免费的内存计算中包含caching,那么它可能会发出错误的警告; 定期清空caching可以抑制这些警告,同时仍然允许该工具注意到“真实”的内存不足时。

    当然,在这种情况下,真正的解决办法是修改监控工具,将caching包含在免费的ram计算中; 清理caching只是一个解决方法,也是一个不好的方法,因为当进程访问磁盘时,caching会快速填充。

    所以,即使我的假设是真实的,caching清理也不是有意义的,相对于没有足够能力解决主要问题的人来说,这是一个解决方法。

    我可以想出一个合理的理由,在夜间的工作中做到这一点。

    在大型系统上,定期删除caching可能会很有用,因此您可以删除内存碎片。

    内核透明的巨大页面支持定期扫描内存,将小页面合并为大页面。 在退化条件下,这可能会导致系统暂停一两分钟(我的经验是在RHEL6中,希望能够改进)。 放下caching可能会让大扫除者有一定的空间可以使用。

    您可能会认为这是禁用透明超大页面的一个很好的理由。 OTOH你可能认为透明巨大页面的整体性能提升是值得的,值得付出每天丢掉一次caching的代价。


    我想到了另外一个你想做的理由,虽然不是在一个cron的工作。 在虚拟化系统将虚拟机迁移到新硬件之前,这是一个非常好的时机。 更less的内存内容复制到新的主机。 当然,你最终必须从存储中读取数据,但是我可能会采取这种权衡。

    我不知道是否有任何虚拟软件实际上这样做。

    只是为了增加我的两分钱:系统非常清楚这些内存页面是caching,当应用程序请求内存时,系统会尽可能多地删除。

    相关的设置是/proc/sys/vm/swappiness ,它告诉内核在新的内存分配期间更喜欢删除内存caching或交换分配的“空闲”的内存页面。

    问题是从2014年开始,但是由于现在存在的一些隐藏的6.8后端问题,对某些人来说可能还是有用的。

    https://github.com/zfsonlinux/zfs/issues/1548描述了zfs的一个问题。 在那里,磁盘空间不会被删除的文件释放,因为如果在zfs之上使用nfs,则文件的inode不会从内核的inodecaching中删除。

    引用bug线程,behlendorf,2015年1月6日写道:

    目前的猜测是,由于某种原因NFS服务器正在保持文件句柄的caching版本。 在NFS服务器丢弃这个文件句柄之前,ZFS不能取消这个文件的链接。 一些轻度testing显示,在服务器上删除caching会导致此引用被丢弃(如NFS文件句柄),此时空间被正确释放。 内存压力也可能导致它下降。

    即夜间回声3> / proc / sys / vm / drop_caches是对这个错误的最简单的修复,如果你不想停机重组你的zfs。

    所以也许不是货运崇拜,但一些相当不错的debugging是原因。

    我有一个台式机,在PAE内核上运行16GB RAM。 一两个小时后,磁盘性能急剧下降,直到我放弃caching,所以我只是把它放到cron。 我不知道这是否是PAE内核的问题,或者如果有足够的内存,caching实现如此缓慢。