OOM杀手无法正常工作,导致操作系统死机


23

多年来,我操作系统的OOM杀手er无法正常工作,并导致系统死机。
当内存使用率很高时,整个系统趋于“冻结”(实际上:变得非常缓慢)数小时甚至数天,而不是终止进程以释放内存。
我所记录的最长期限是辞职以进行重置之前的7天。
当即将达到OOM时,iowait很高(〜70%),然后变得不可测量。
工具:iotop已经表明,每个程序都从我的硬盘驱动器中以非常高的吞吐量(每数十MB /秒)读取数据。
这些程序正在读什么?
-目录层次结构?
-可执行代码本身?
我现在不完全是。

[编辑]在撰写此消息时(2017年),我使用的是最新的ArchLinux(4.9.27-1-lts),但几年前已经遇到了这个问题。
我在各种Linux发行版和不同的硬件配置中都遇到了相同的问题。
当前(2019年),我正在使用最新的Debian 9.6(4.9.0),我有16 GB的物理内存,安装了我的操作系统的SSD,没有任何交换分区。

由于我拥有的内存数量很大,因此我不想启用交换分区,因为这只会延迟问题的解决。
同样,使用SSD频繁交换可能会降低磁盘的使用寿命。
顺便说一句,无论是否有交换分区,我都已经尝试过,事实证明,这样做只会延迟问题的解决,而不能解决问题。

对我来说,问题是由于Linux从缓存中删除了必要的数据而导致的,这导致系统死机,因为它每次都必须从硬盘读取所有内容。

我什至不知道Linux是否不会删除正在运行的程序的可执行代码页,这将解释为什么通常不读取大量数据的程序在这种情况下会表现出这种方式。

我已经尝试了几种方法来解决此问题。
一种是设置/proc/sys/vm/min_free_kbytes1000000(1 GB)。
因为这1 GB应该保持可用,所以我认为Linux将保留此内存以缓存重要数据。
但这没有用。

另外,我想补充一点,即使这可能听起来在理论上很不错,限制了虚拟内存到物理内存的大小尺寸是有用的,通过定义/proc/sys/vm/overcommit_memory2不端正在我的处境技术上是可行的,因为那种应用由于某些原因,我使用的虚拟内存需要比有效使用的虚拟内存更多。
根据该文件/proc/meminfo,该Commited_AS值通常高于我的系统上物理内存的两倍(16 GB,Commited_AS通常大于32 GB)。

我在/proc/sys/vm/overcommit_memory默认值:上遇到了这个问题0,并且有一段时间我将其定义为:1,因为我更喜欢由OOM杀手杀死的程序,而不是行为不当,因为它们不检查mallocwhen的返回值。分配被拒绝。

当我在IRC上讨论此问题时,我遇到了其他Linux用户,他们也遇到了同样的问题,因此我想很多用户对此感到担忧。
对我来说,这是不可接受的,因为即使Windows可以更好地处理高内存使用情况。

如果您需要更多信息,请提出建议。

文档:
https : //en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm。 txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

他们谈论它:
为什么linux out-of-memory(OOM)杀手不自动运行,而是在sysrq-key上运行?
为什么OOM杀手有时无法杀死资源猪?
预加载OOM杀手
是否可以在强制交换时触发OOM杀手?
如何避免在OOM附近出现高延迟?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843


1
我认为这是您应该期望的,如果您遇到麻烦,但是您并没有真正接近100%的“已使用”,即文件支持的内存使用过多,被视为“ buff /缓存”。(U,此措辞假设您的tmpfs分配是微不足道的,因为它们显示为“ buff / cache”,但不能分页到物理文件系统)。 min_free_kbytes不相关,不是缓存页面的保留。AFAICT没有一个vm sysctls允许保留任何专门用于缓存页面的内存,即限制MAP_ANONYMOUS分配:(
。– sourcejedi

2
多年来,我一直在寻找针对此确切问题的解决方案,但没有成功。我相信在用SSD替换HDD之后,我首先注意到了这个问题,这也使我完全禁用了交换功能,但是我不能真正保证它在这些更改之前从未发生过,因此可能无关紧要。我在Archlinux上。
brunocodutra

2
我刚刚在Arch Linux论坛上发布了有关此内容的信息。
伊格纳特

1
@ dsstorefile1谢谢,我会尝试的。但是,当内核在这种情况下无法正常运行时,它如何确定触发OOM杀手?
M89

1
当chrome设法通过我的所有RAM泄漏时,它很有用...(尽管我最终也添加了一个实际的磁盘交换分区,并最终升级到了相当数量的RAM)
Gert van den Berg

Answers:


5

我发现(同样的事情)有两种解释,为什么kswapd0并不断读盘发生 OOM杀手杀死违规的过程之前得好:

  1. 看到这个askubuntu SE答案的答案和评论
  2. 在Unix SE上查看答案和David Schwartz对这个答案的评论

我将在这里引用来自1.的评论,它真正使我大开眼界,为什么在冻结所有内容时却不断读取磁盘:

例如,考虑一种情况,您的交换次数为零,而系统几乎用完RAM。内核将从例如Firefox中获取内存(之所以可以这样做,是因为Firefox运行的是从磁盘加载的可执行代码-如果需要,可以再次从磁盘加载该代码)。如果Firefox随后需要在N秒钟后再次访问该RAM,则CPU会生成“硬故障”,从而迫使Linux释放一些RAM(例如,从另一个进程中获取一些RAM),从磁盘上加载丢失的数据,然后允许Firefox继续运行。通常。这与正常交换非常相似,而kswapd0做到了。– Mikko Rantalainen 2月15日在13:08

如果有人有办法禁用这种行为(也许用什么选项重新编译内核?),请尽快告诉我!非常感谢,谢谢!

更新:到目前为止我发现的唯一途径是通过打补丁的内核,它为我的作品禁用掉期(即。CONFIG_SWAP is not set但交换启用它不为别人打工)似乎 ; 请参阅问题中的补丁。


删除无效的文本。不要在文本中用“ EDIT”标记编辑。从修订历史中可以明显看出它们。
库萨兰达

1
@Kusalananda应该鼓励此用户,因为他可能是贡献最大的那个人。
M89

@Kusalananda我认为保留它们很重要,这样其他人才能看到(其他)尝试过的和无效的。也许UPDATE反而EDIT会更好?

@MarcusLinsner不,对不起,您误会了。当您提出问题时,显示您已尝试过的方法。该答案应为问题是正确的,因为它是目前提出的。我的意思是,一个编辑甚至要求读者忽略先前的编辑。如果您有兴趣查看编辑历史记录,可以在此处查看
库萨兰达

0

内存控制器中的memory.min参数cgroups-v2应该有所帮助。

即,让我引用:

硬内存保护。如果cgroup的内存使用量在其有效的最小范围内,则在任何情况下都不会回收cgroup的内存。如果没有可用的不受保护的可回收内存,则将调用OOM杀手。

来源:https : //www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html


您能详细说明一下吗?您的答案在回答OP问题方面有些不足。
悖论
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.