在我们的服务器中,我们习惯于在午夜删除缓存。

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


运行代码时,它似乎释放了很多RAM,但是我确实需要这样做。可用RAM不是浪费吗?

评论

找到把它放进去的人,问他为什么这样做。您猜对了,没有明显的理由。

调试内核。就是这样这实际上并没有释放任何RAM。顾名思义,它会删除缓存,从而降低性能。

@ivcode然后,您应该找到并解决该服务器的问题,而不要避免引起该问题的情况。如果每次我向右急转弯时汽车都失速了,那么避免急转弯就是一个糟糕的解决办法。
相关thedailywtf.com/Articles/Modern-Memory-Management.aspx强烈认为这是个坏主意。

相关的“问题”的有用描述:linuxatemyram.com

#1 楼

您是100%正确的。释放内存不是一个好习惯。这可能是货物崇拜系统管理的一个例子。

评论


+1代表提及“货物崇拜系统管理”。任何不知道该术语及其含义的系统管理员都应被解雇。

–Tonny
2014年5月20日上午10:22

@Tonny:那我们就没有sysadmin部门了:(

– PlasmaHH
2014年5月20日19:44

像大多数人类一样,我喜欢简短的断言,但得到了很多人的认可,但是引用或推理将使我的超我获得+1。

–亚伦·霍尔
2014年5月23日在20:22

如果您不介意的话,请解释货运管理以及上述内容。也许在后续编辑中?我仍保留+1 ...:P

–亚伦·霍尔
2014年5月26日在2:56



“有可能,尽管您的应用程序可能没有使用这些RAM,但是Linux正在积极地将其缓存到其内存中,即使该应用程序需要内存,它也不会释放其中的某些缓存,而是开始交换。不太具体。在实践中,内存管理并不是完美的,当出现缺陷时转动旋钮是一件好事。

–丹·普里兹(Dan Pritts)
16-4-12在18:07



#2 楼

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

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

评论


+1解释为什么这是一个坏主意。

–食人魔诗篇33
2014年5月20日17:00

@ananthan-关于rsync的帖子建议删除缓存-unix.stackexchange.com/a/510800

–有动力
20年1月3日,19:28



@Motivated并且,如果您不完全信任内存(即非ecc RAM的高速缓存段中可能有一个翻转位),这在一定意义上说,但这不是为了加快速度,而是为了最大程度地减少内存错误更改rsync的机会结果。在具有ecc内存的服务器上,发生这种情况的可能性非常低,以至于您不必理会。

–P.Péter
20-4-22在14:51



#3 楼

像这样删除高速缓存的原因是为了对磁盘性能进行基准测试,并且是存在磁盘缓存的唯一原因。
运行I / O密集型基准测试时,您要确保尝试各种设置实际上都是磁盘I / O,因此Linux允许您丢弃缓存而不是完全重新引导。

引用该文档:


文件不是控制各种内核高速缓存(inodes,dentries,页面高速缓存等)增长的一种方法,当其他地方需要内存时,内核会自动回收这些对象
>在系统上。

使用此文件可能会导致性能问题。由于它会丢弃
缓存的对象,因此重新创建被丢弃的对象可能会花费大量的I / O和CPU
,特别是如果它们使用量很大。
因此,请在外部使用建议不要使用测试或调试环境。


评论


当然,根据您要尝试执行的操作,即使完全重新引导也可能无法充分清除磁盘缓存。

–用户
2014年5月21日15:01

设计目标是“当需要内存时内核自动回收这些对象”,但这可能并不总是实际的行为。

–丹·普里兹(Dan Pritts)
2015年1月14日15:51



@DanPritts是什么让您认为事实并非如此?

–乔
15年1月28日在3:24

很明显的情况是,当您想清除RAM以允许分配更多(非透明)大页时;另一种情况是透明的大页面垃圾收集暂停错误(请参阅我在该问题上其他地方的回答/评论)。但是我的评论只针对一般情况。有时,操作该系统的人员比设计/实现该系统的人员了解得更多。通常,不是-这就是他们的评论试图防止的内容。我很高兴

–丹·普里兹(Dan Pritts)
15年1月28日在15:24

#4 楼

这里的基本思想可能还不错(只是非常幼稚和令人误解):可能存在正在缓存的文件,这些文件在不久的将来不太可能被访问,例如日志文件。这些“吃掉”的内存,稍后在必要时将由操作系统以一种或另一种方式释放。

取决于交换设置,文件访问模式,内存分配模式以及更多不可预测的事情,有可能发生的情况是,当您不释放这些缓存时,它们稍后将被强制重用,这比从未使用的内存池分配内存要花费更多时间。在最坏的情况下,Linux的swappiness设置将导致程序内存被换出,因为linux认为这些文件在不久的将来比程序内存更可能被使用。
,linux经常会猜错,在大多数欧洲证券交易所(当地时间0900左右)开始时,服务器每天只会执行一次操作,因此需要交换以前写出的内存,这是因为编写日志文件,压缩它们,然后将它们复制等将缓存填满,以至于必须将其交换出去。绝对不是。这里的解决方案是告诉linux它不知道的东西:这些文件可能将不再使用。这可以通过编写应用程序使用posix_fadvise()之类的东西或使用cmd行工具(例如vmtouch)(也可以用于查看事物以及缓存文件)来完成。从缓存中删除不再需要的数据,并保留应缓存的内容,因为当删除所有缓存时,必须从磁盘重新读取很多内容。在最坏的时刻:需要时;导致您的应用程序出现明显且通常不可接受的延迟。

您应该拥有的系统可以监视您的内存使用模式(例如,是否有交换内容),然后进行相应的分析并采取相应的措施。解决方案可能是在一天结束时使用vtouch逐出一些大文件。也可能是增加更多的内存,因为服务器的每日高峰使用量就是这样。

评论


我服务器上的所有应用程序都在nohup上运行。也许nohup.out正在缓存并耗尽了内存?

– ivcode
2014年5月21日在8:27

@ivcode:这可能是一个原因,请检查nohup.out的大小。也许使用vmtouch找出其中有多少缓存。

– PlasmaHH
2014年5月21日在8:32

由于nohup.out迅速增长,我每15分钟就有一份cron工作来负责/ dev / null> path / nohup.out。也许linux正在缓存nohup.out,即使我正在清除它

– ivcode
2014年5月21日在8:41

@ivcode如果不需要nohup的输出,则应将其重定向到/ dev / null。听起来您有时在系统上有一些经验不足的系统管理员。有关如何将nohup的输出定向到/ dev / null的信息,请参见stackoverflow.com/questions/10408816/…

–大卫·威尔金斯(David Wilkins)
2014年5月21日在13:28



尽管会每隔15分钟清除一次nohup.out,但如果应用程序进程由于某种原因而被终止,则nohup.out将自动从另一个脚本进行备份。我尝试了vmtouch。这确实是一个非常好的工具

– ivcode
2014年5月21日15:02

#5 楼

我看到启动一堆虚拟机时,丢弃缓存非常有用。或其他使用大页面的东西,例如某些数据库服务器。Linux中的大页面通常需要对RAM进行碎片整理,以便找到2MB的连续物理RAM放入页面中。释放所有文件缓存使此过程变得非常容易。

评论


我赞成指出二阶偏见是对丢弃缓存的响应。

–诺亚·斯珀雷尔(Noah Spurrier)
2014年5月23日在8:44

同样,在高内存节点(1Tb)上的HPC应用程序中,读入一些大文件会导致缓存大量内存。因为许多HPC应用程序执行数百GB的malloc,所以系统可能会停滞数小时,因为一旦系统到达高速缓存的内存“边界”,迁移过程便会在NUMA节点之间毫无意义地移动碎片内存的小块。更糟糕的是,除了在系统中欺骗系统分配它可以立即分配的所有2MB微小块,然后释放它们,让大页碎片整理和应用程序正常运行外,您无法在用户领域释放缓存。

–user1649948
17 Mar 18 '17 2:16



+1创建大页面的命令(sysctl -w vm.nr_hugepages = ...)什至不起作用,除非我先删除高速缓存(Arch linux)。

–亚历山大·杜宾斯基(Aleksandr Dubinsky)
17年5月24日19:13

#6 楼

可能是在没有人真正掌握问题的技能或经验的情况下,采用这种方法来稳定系统的。
释放资源
释放缓存实际上会释放一些资源,但是这样做的副作用是使系统实际上很难执行其尝试执行的操作。如果系统正在交换(尝试从磁盘交换分区中读取和写入磁盘,比实际速度快得多),则定期删除高速缓存可以缓解症状,但无法解决原因。什么是吞噬内存?
您应该确定是什么导致大量内存消耗,从而导致删除高速缓存似乎可行。这可能是由于任何数量的配置不正确或只是简单地错误使用服务器进程引起的。例如,在一台服务器上,当Magento网站在15分钟的间隔内达到一定数量的访问者时,我见证了内存利用率最大化。这最终是由于将Apache配置为允许太多进程同时运行而引起的。进程太多,占用大量内存(Magento有时是野兽)=交换。
底线
不要仅仅假设这是必要的。积极主动地找出原因,并在其他人认为错误的情况下敢于禁用它,并观察系统-了解真正的问题所在并加以解决。

#7 楼

Linux / m68k实际上有一个内核错误,该错误会导致kswapd发疯并吞噬100%的CPU(如果还有其他CPU绑定任务,例如Debian二进制软件包autobuilder – vulgo –已经运行),则该错误可能会导致(每隔几个小时运行一次此特定命令即可缓解这种情况;并非总是如此。 Q60,Sun3)系统;-)

在这种情况下,插队的人要么遵循一些可疑的建议,要么充其量是过时的建议,或者对如何使用RAM有所误解(现代思维确实说“空闲RAM浪费了RAM”并建议进行缓存),或“发现”此问题“解决”了其他问题(并且懒得寻找适当的解决方法)。

评论


“导致kswapd疯狂的内核错误”-这是哪个错误?

–本
15年8月3日,19:06

@Ben看到了这个线程(此消息和一些后续操作,其中之一包括猜测它可能来自何处)

– mirabilos
15年8月4日在10:54

我遇到了类似的问题(尽管它是x86_64),目前唯一的解决方案是删除缓存serverfault.com/questions/740790/…

–费尔南多
15年12月4日在15:08

@Fernando我在m68k盒子上也有一个“ drop caches” cronjob☹

– mirabilos
2015年12月4日在15:28

#8 楼

我可以想到一个合理的理由,在每晚的Cron工作中执行此操作。

在大型系统上,定期删除缓存可能很有用,这样您就可以消除内存碎片。

内核透明大页面支持会定期进行内存扫描,以将小页面合并为大页面。在退化的条件下,这可能导致一两分钟的系统暂停(我的经验是在RHEL6中使用;希望它有所改进)。丢弃缓存可能会使大页面清扫程序有一定的工作空间。

您可能会认为这是禁用透明大页面的一个很好的理由。 OTOH您可能会相信透明大页带来的整体性能提高值得拥有,并且值得付出每天丢失一次缓存的代价。


我想到了您想这样做的另一个原因,尽管不是在做正式工作。在虚拟化系统将VM迁移到新硬件之前,这将是一个很好的时机。较少的内存内容可复制到新主机。当然,您最终将不得不从存储中读取内容,但是我可能会权衡取舍。

我不知道是否有任何virt软件实际上可以做到这一点。 />

评论


您有任何资料来源吗?这听起来像是应该在内核中修复的问题。

–祖父母
2015年1月14日15:59

我对透明大页面的停顿有个人经验。 RHEL6,Dell R810、4CPU,64GB RAM。禁用透明的大页面(有一个/ proc文件可以这样做)立即修复了暂停。当时我没有尝试过缓存删除技术。相反,我将Java应用程序重新配置为使用非透明的大页面,并禁用了透明的大页面。 IIRC,我们对情况进行了充分调查,以意识到我们并不是唯一受影响的人,并且Red Hat知道了这个问题。

–丹·普里兹(Dan Pritts)
2015年1月14日在16:07

您好Dan,我在服务器上进行了相同的设置。我使用大量数据进行工作,并且在同一Python程序进行10次以上的计算(第一次计算时间的2-3倍)后,性能急剧下降。如果看一看,内存缓存大小非常大,超过100 GB。而且,如果刷新此内存缓存,然后重新运行程序,我将获得最初的计算时间。您是否有任何文件或信息可以分享这种现象?谢谢。

– Axel Borja
16-11-24在16:41



access.redhat.com/solutions/46111对其进行了描述。您可以禁用透明的大页面,以查看是否是您的问题。

–丹·普里兹(Dan Pritts)
16-11-24在18:49



#9 楼

一个原因可能是该站点正在运行某种监视,该监视检查免费RAM的数量,并在免费RAM下降到一定百分比以下时向管理员发送警告。如果该监视工具足够愚蠢,无法在免费ram计算中不包括缓存,则它可能会发送错误警告;定期清空缓存可以抑制这些警告,同时仍然允许工具在“实际”内存变低时发出通知。

当然,在这种情况下,真正的解决方案是将监视工具修改为在免费内存计算中包括缓存;清理缓存只是一种解决方法,也是一个不好的选择,因为当进程访问磁盘时缓存会快速重新填充。这是有道理的,对于没有足够能力解决主要问题的人来说,这是一种解决方法。

#10 楼

只需加上我的两分钱:系统非常了解这些内存页是缓存,并且在应用程序请求内存时会根据需要减少。新的内存分配过程中,内核倾向于删除内存缓存或交换“空闲”分配的内存页面。

#11 楼

问题是从2014年开始的,但是由于这一问题在某些隐藏的centos 6.8后端上一直存在,因此对于某些人可能仍然有用。

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

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


当前猜测是出于某种原因,NFS服务器是
保留文件句柄的缓存版本。在NFS服务器删除该文件句柄之前,ZFS无法取消链接该文件。某些轻度测试
显示,在服务器上删除高速缓存将导致删除此引用
(如NFS文件句柄),此时正确释放空间。内存压力也可能导致内存下降。


夜间回声3> / proc / sys / vm / drop_caches是该错误的最简单解决方案,如果您不希望因停机而重组zfs。

所以也许不是货物崇拜管理,但是一些相当好的调试是原因。

#12 楼

这在NUMA(非统一内存访问)系统上可能是有意义的,在该系统上,通常每个CPU(套接字)可以透明地访问所有内存,但是与并行HPC应用程序相关联,其自身的内存可以比其他套接字的内存访问得更快。 br />
许多简单的并行应用程序倾向于从单个进程执行文件I / O,因此在分配给磁盘高速缓存的单个NUMA节点上留下大量内存,而在另一个NUMA节点上保留了内存可能大部分是免费的。在这种情况下,据我所知,由于Linux内核中的缓存回收过程仍不支持NUMA,因此在已将内存分配给缓存的NUMA节点上运行的进程被迫在另一个NUMA节点上分配内存,只要另一个节点上有可用的RAM,从而降低了性能。

对于非并行应用程序,此问题不太可能出现。

#13 楼

当页面缓存很大(比您当前的交换使用量大得多)并且交换和交换发生时,这是您需要删除缓存的时候。
我已经看到了以下情况:我的一台运行Ubuntu 16.04LTS的MariaDB数据库服务器,而Linux只是选择增加交换使用量,而不是删除未使用的页面缓存。我的系统中已经禁用了透明的大页面,因为TokuDB要求将其禁用。
无论如何,这可能不是bug,但是linux仍然在做这种行为令我感到困惑。各种消息来源都说Linux在应用程序请求页面缓存时会删除它:



https://www.linuxatemyram.com/

https: //www.thomas-krenn.com/zh-CN/wiki/Linux_Page_Cache_Basics

但是事实并非如此简单。解决方法是:


定期执行drop缓存
在需要时执行drop缓存(使用vmstat 1进行监视器监视以换出活动)
建议linux删除某些文件使用dd或python-fadvise之类的工具从缓存(例如apache日志文件)中获取数据。参见https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache


示例dd run:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

python-fadvise示例:

pyadvise -d /var/log/apache2/access_log.1

#14 楼

我有一台在PAE内核上运行16GB RAM的台式机。一两个小时后,磁盘性能会急剧下降,直到删除高速缓存,因此我将其放入cron。我不知道这是否是PAE内核的问题,或者如果有足够的内存,那么缓存的实现是如此之慢。

评论


这是“货运邪教”系统管理的一个典型示例:您无需掩盖并解决问题,而只是掩盖它。

–迈克尔·汉普顿
14年5月23日在13:03

有时权宜之计是正确的解决方案。它可能只是推迟解决实际问题,或者可能是实际情况所需的解决方案。即使是不好的做法,它仍然不是“崇拜”。有一个已证明的因果关系:丢弃缓存和磁盘性能得到改善。

–丹·普里兹(Dan Pritts)
15年1月14日在15:49

CCSA最初定义的一部分是一种将因果关系误认为因果关系的趋势,在这里就是了。通过解决相关但非因果的实体来掩盖问题是解决问题的最佳方法,这是CCSA的概念正试图警告的问题。

– underscore_d
2015年10月6日在1:04