为什么OOM-Killer不能杀死要求太多的过程？

在此说明，可以通过overcommit_memory和配置OOM-Killer ：

2 =没有过量使用。如果要求太多，分配将失败。
0，1 =过量使用（启发式或始终使用）。当实际访问太多内存时，根据某些启发式方法终止某些进程。

现在，我可能完全误解了，但是为什么没有选项（或者为什么不是默认选项）杀死实际上试图访问它分配的过多内存的进程呢？

linux out-of-memory

— 马丁·巴
source

如果关键的系统进程要求太多的内存怎么办？

— 劳伦斯2014年

首先-它可以做到这一点。但是，该问题的最大问题是，如果某个进程在请求内存，那么它很可能是新执行的，换句话说，这是当前处理中涉及的新进程。您是希望OOM允许您未开放3天的即时通讯客户端继续浪费系统内存，还是希望YouTube今年实际加载一些时间？linuxatemyram.com

— mikeserv

这实际上是该no overcommit选项的作用。如果某个进程需要太多内存，它将失败。如果检查错误，通常会杀死自己；如果不这样做，则在尝试取消引用malloc()返回的空指针时，可能会遇到“分段错误” ，并且将崩溃。

— Barmar 2014年

请注意no overcommit，根据引用的来源（例如kernel.org/doc/Documentation/vm/overcommit-accounting），实际上是2 模式。我想我会相应地编辑您的问题。

— hans_meine

考虑这种情况：

您有4GB的可用内存。
错误的进程分配了3.999GB。
您打开任务管理器以终止失控的过程。任务管理器分配0.002GB。

如果被杀死的进程是请求内存的最后一个进程，则任务管理器将被杀死。

要么：

您有4GB的可用内存。
错误的进程分配了3.999GB。
您打开任务管理器以终止失控的过程。X服务器分配0.002GB来处理任务管理器的窗口。

现在，您的X服务器被杀死。它没有引起问题；那只是“在错误的时间在错误的地方”。当没有剩余空间时，它恰好是分配更多内存的第一个过程，但这并不是使用所有内存开始的过程。

— 用户名
source

扩展您的示例意味着，如果某个进程正在消耗您99.999％的内存，则您将永远无法杀死它，因为任何可能杀死它的东西都将需要内存，因此在被错误的进程杀死之前，它会被杀死！

— 雪橇2014年

请注意，这是Linux的哲学，不是必要的事实。Windows 3.0通过为OOM处理保留足够的内存（包括必要的对话框）解决了该问题。

— MSalters 2014年

@MSalters：但这实际上不适用于该示例；这个例子是关于一个进程，它几乎保留了所有内存。不足以杀死OOM。显然，必须在任何OS上保留足够的内存以用于OOM处理。但是调用OOM处理的进程将是保留内存的下一个进程，而不是行为异常的进程。当然，除非您表示Windows 3.0始终为运行任务管理器保留了足够的内存，否则除非OOM处理程序总是提示用户该进程被杀死。（哪个！=杀死令人讨厌的进程）

— Aleksi Torhamo

@AleksiTorhamo：我的确是后者。Windows 3.0没有完善的任务管理器，它具有著名的蓝屏，其内存已预先分配。

— MSalters