多年来,我操作系统的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_kbytes
为1000000
(1 GB)。
因为这1 GB应该保持可用,所以我认为Linux将保留此内存以缓存重要数据。
但这没有用。
另外,我想补充一点,即使这可能听起来在理论上很不错,限制了虚拟内存到物理内存的大小尺寸是有用的,通过定义/proc/sys/vm/overcommit_memory
到2
不端正在我的处境技术上是可行的,因为那种应用由于某些原因,我使用的虚拟内存需要比有效使用的虚拟内存更多。
根据该文件/proc/meminfo
,该Commited_AS
值通常高于我的系统上物理内存的两倍(16 GB,Commited_AS通常大于32 GB)。
我在/proc/sys/vm/overcommit_memory
默认值:上遇到了这个问题0
,并且有一段时间我将其定义为:1
,因为我更喜欢由OOM杀手杀死的程序,而不是行为不当,因为它们不检查malloc
when的返回值。分配被拒绝。
当我在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
min_free_kbytes
不相关,不是缓存页面的保留。AFAICT没有一个vm sysctls允许保留任何专门用于缓存页面的内存,即限制MAP_ANONYMOUS分配:(