是否可以更早地干预OOM杀手？

我尝试将开发系统调整为最大的可靠性。我禁用了交换功能，因为对于GUI使用，它主要使计算机无响应，从而不再可用。但是，如果攻击性的应用吞噬了内存，那么似乎有一些机制可以提高速度，从而最大限度地利用内存。没有硬盘交换操作，但是系统同样没有响应。因此，我想让OOM杀手kick脚，然后系统对内存增益进行任何特殊的努力。例如，如果可用物理内存少于100 MB，是否可以配置OOM杀手执行操作？

我也为这个问题而苦恼。我只是希望我的系统无论如何都可以保持响应，并且我宁愿丢失进程也不愿等待几分钟。使用内核oom Killer似乎无法实现这一目标。

但是，在用户空间中，我们可以做任何我们想做的事情。所以我写了Early OOM Daemon（https://github.com/rfjakob/earlyoom），一旦可用RAM低于10％，它将杀死最大的进程（通过RSS）。

如果没有Earlyoom，通过多次启动http://www.unrealengine.com/html5/可以很容易地锁定我的机器（8GB RAM）。现在，有罪的浏览器选项卡在事情失控之前就被杀死了。

内核的默认策略是，只要有可用的物理内存，应用程序就可以继续分配虚拟内存。直到应用程序触摸分配给它们的虚拟内存后，才真正使用物理内存，因此应用程序可以分配的内存比系统要多得多，然后再开始使用它，导致内核内存不足并触发内存不足（OOM）杀手。但是，在终止进程之前，它已导致磁盘高速缓存被清空，这使系统响应一段时间，直到高速缓存重新填充为止。

您可以通过将默认值2写入来更改默认策略以禁止内存过量使用/proc/sys/vm/overcommit_memory。默认值为/proc/sys/vm/overcommit_ratio50，因此内核将不允许应用程序分配ram + swap的50％以上。如果没有交换，则内核将不允许应用程序分配超过50％的内存，其余50％留给缓存。这可能有点过分，所以您可能希望将此值增加到大约85％，以便应用程序最多可以分配85％的内存，而将15％留给缓存。

对我来说，设置vm.admin_reserve_kbytes = 262144可以完成此任务。在系统完全不响应之前，OOM杀手进行干预。

其他答案都有很好的自动解决方案，但我发现也可以SysRq在事情失控时启用密钥。使用该SysRq键，您将手动向内核传递消息，并且SysRQ + REISUB即使用户空间已完全冻结，也可以执行诸如安全重启（带有）的操作。

要允许内核侦听请求，请设置kernel.sysrq = 1或仅启用您可能会与位掩码一起使用的功能（在此处记录）。例如，kernel.sysrq = 244将启用安全重启所需的所有连击，以及使用手动调用OOM杀手SysRq + F。

低内存条件和OOM杀手无法达到可靠性。

在壁橱里组织一个聚会并将“清理我的壁橱”放在您的小播放列表上是错误的。

是否可以更早地干预OOM杀手？

这样做会带来意想不到的副作用，因为您无法控制被杀死的内容。

我尝试将开发系统调整为最大的可靠性。

最大的可靠性包括测试您的系统并基于这些测试来改进您的系统。

只是调整随机的东西并不会带你到任何地方...

我禁用了交换功能，因为对于GUI使用，它主要使计算机无响应，从而不再可用。但是，如果攻击性的应用吞噬了内存，那么似乎有一些机制可以提高速度，从而最大限度地利用内存。

由于内存不足，禁用交换不会改善行为，反之亦然。

为了在这种情况下提高可靠性，请添加更多的内存，以使您的系统具有更高的响应速度，并且在没有用户意图的情况下不会杀死任何随机进程。您不应该在内存不足的情况下使用这种机制，尤其是在开发环境中……

没有硬盘交换操作，但是系统同样没有响应。

内存不足的情况确实会导致无响应，无论您是否进行了交换。

因此，我想让OOM杀手kick脚，然后系统对内存增益进行任何特殊的努力。

如上文所述，付出特殊的努力只会弊大于利。相反，您可以杀死不需要的进程，但是我想您不能这样做，因此OOM将杀死您需要的进程。

例如，如果可用物理内存少于100 MB，是否可以配置OOM杀手执行操作？

可能会，但是，如果您仅购买一些额外的内存，而这些天实际上并不需要太多钱，那么您可以获得更高的投资回报。如果您继续在内存不足的情况下工作，那么从长远来看，您会陷入困境。OOM就像法警一样，对您没有帮助，对操作系统有帮助...