☰

假设你这样做

tag-icon • tag-icon linux ubuntu debian ubuntu-14.04
假设你这样做

如何OOM killer在 Ubuntu 14.04 上禁用？ 有描述这里，但似乎对原帖者不起作用。如果能得到一个有明确步骤的答案就好了。

答案1

这是一个 XY 问题；也就是说，无论你是否知道，你确实有一个问题（X），并且相信你可以通过解决一个不同的问题，即问题 Y。

为什么您想禁用 oomkiller 吗？这就是您需要解决的 X 问题。您应该做的是调查并详细说明问题 X。提供详细信息，我们可能会帮助您。

解决 Y 问题并禁用 oomkiller 通常是非常糟糕的想法这将一定造成更大的问题可能解决。

调用 oomkiller 是绝望的最后手段当事情在记忆方面出现问题，厄运迫在眉睫时。你的飞船上有六名乘客，还有一个小时，而氧气供应只有五个工时。你可能会认为随机杀死一名乘客（不是随机的 -新陈代谢更快的) 是一件可怕的事情，但另一种选择是让所有六名乘客在停靠前十分钟窒息死亡。

假设你这样做

您成功禁用了 oomkiller。系统重新启动并正常运行。现在可能会发生两件事：

  • 杀手无需调用。你所做的一切都是徒劳的。
  • 杀手确实需要调用。

但为什么需要 oomkiller 呢？这是因为一些进程需要内存，而系统发现它无法提供这些内存。

有一个我们称之为“memoryhog”的进程，它本来会被 oomkiller 杀死，但现在这种情况没有发生（因为如果这种情况一直发生，就不会有任何变化 - 那么我们为什么要这么麻烦呢？）。什么做反而会发生？

选项 1：OOM 意味着死亡

您在启动时发出了这些命令

sysctl vm.panic_on_oom=1
sysctl kernel.panic=5

或者将其添加到/etc/sysctl.conf并重新启动

vm.panic_on_oom=1
kernel.panic=5

一旦系统被占用，它就会崩溃并在 5 秒后重新启动。

结果不太好。

选择 2：如果可能的话，杀死其他人

在启动时，您将某些进程归类为“可消耗”，将其他进程归类为“不可消耗”。例如，Apache 可能是可消耗的，而 MySQL 则不是。因此，当 Apache 遇到一些异常大的请求时（在 LAMP 系统上，通常是由于“简单修复”将 PHP 内存分配设置为异常大的值而不是更改某些内存限制或泄漏方法而导致的），即使 MySQL 占用更多内存，Apache 子进程也会被终止。这样，客户只会看到一个空白页，点击 RELOAD，获取另一个... 最后停止。

您可以通过在启动时记录 MySQL 的 PID 并调整其 OOM 评级来实现：

echo -15 > /proc/$( pidof mysql )/oom_adj

不过在这种情况下我也会调整Apache 的子配置文件。

请注意，如果此选项解决了您的问题（通常可以解决，或者更确切地说似乎），这意味着你有一个问题其他流程（例如，过大的 PHP 流程。它源于次优算法或数据选择阶段。您沿着这条链前进，直到找到真正需要解决的问题）。

安装更多 RAM 可能也会产生同样的效果。

使用此选项，如果 MySQL 本身增长过多（例如，因为你弄错了值innodb_pool_size- 我曾经这样做过一次），那么 MySQL 将被终​​止反正。

选项 3：永不曾经终止 $MYPRECIOUSSS 进程

与上述相同，但现在调整设置为 -17。

我现在谈论的是 MySQL，但大多数程序的行为方式都是一样的。我确信 PostgreSQL 和 Oracle 都是这样的（它们有权这样做。滥用 RDBMS 后果自负）。

这个选项很危险，因为 oomkiller 会杀死其他人，可能反复， 但是重要的是，可能是因为 $MYPRECIOUSSS 本身。

因此，失控的进程将被驱逐其他所有人从内存中取出，直到系统无法使用，并且你甚至无法登录检查或执行任何操作。不久之后，随着可用内存的稳步减少，MySQL 将破坏其自身的状态信息并严重崩溃，您将面临一个漫长的fsck会话，随后是艰苦的表修复，然后是仔细的事务重建。

我可以根据自己的悲惨经历告诉你，管理层将会非常不开心而实际上，这是一颗定时炸弹。人们会互相指责（MySQL 配置错误、Apache 存在漏洞、OOMKiller 疯了、黑客......），所以“一个人”可能是“很多人”。然而，对于第三种选择，我再怎么强调也不为过，需要完整、充分、不断更新和监控备份，和恢复测试。

选项 4 - “关闭” OOMkiller

这个选项可能看起来像玩笑就像老 Windows XP 技巧“如何永远避免蓝屏！”一样 - 实际上确实有效...通过设置鲜为人知的变量使他们品红。

/etc/sysctl.conf但是，您可以通过编辑文件并添加以下行来使 oomkiller 永远不会被调用：

vm.overcommit_memory = 2
vm.overcommit_kbytes = SIZE_OF_PHYSICAL_MEMORY_IN_K

然后运行命令sysctl vm.overcommit_memory=2并sysctl vm.overcommit_kbytes=...避免需要重新启动。您希望 overcommit_kbytes 稍微较少的比物理可用内存更多。

现在会发生什么？如果系统有足够的内存，则什么也不会发生 - 就像您什么也没做一样。

当系统内存不足时，新的进程将无法启动或在启动时崩溃。它们需要内存，但内存不足。因此它们不会被“oomkilled”，而是“因内存不足错误而被killed”。结果完全相同，这就是为什么有些人可能认为这是一个笑话。

我自己的推荐

调查系统内存不足的原因。这可能是天生无法避免的、可以补救的或完全可以避免的。如果天生无法避免，则将问题级别提高，并要求安装更多内存。

如果是由于错误或错误输入或在临界状态之前可以识别的情况而导致的失控过程，则可补救的。您需要重新设计流程，并为此建立案例。

也可能会发生这样的情况：通过在不同的服务器之间拆分服务，或者更仔细地调整一个或多个进程，或者（再次）重新设计有故障的进程，可以完全避免该问题。

在某些情况下，更有效的解决方案可能是“投入一些资金”——如果你的服务器有 256GB RAM 的问题，而且你知道在可预见的未来最多需要 280GB，那么升级到 320GB 可能只需要 3,000 美元，全包费用，而且可以在周末完成——相比每天 150,000 美元的停机成本，或四个编程人员每月 14,000 美元的成本，这真是一笔划算的交易，和即使在日常条件下也可能会提高性能。

另一种选择（在内存不足的情况下也可以节省一些时间）是设置一个非常大的交换区域，并根据需要激活它。假设我们有 32 GB 的可用空间/var/tmp（并且它不是内存支持的）：

dd if=/dev/zero of=/var/tmp/oomswap bs=1M count=32768
# or: fallocate -l 32g /var/tmp/oomswap
chmod 600 /var/tmp/oomswap
mkswap /var/tmp/oomswap
swapon /var/tmp/oomswap

这将创建一个 32Gb 的文件，用于为各种进程提供一些喘息空间。您可能还想检查并可能增加 swappiness：

cat /proc/sys/vm/swappiness

Ubuntu 14.04 的默认 swappiness 为 60，这对于大多数用户来说已经足够了。

sysctl vm.swappiness=70

答案2

echo 2 > /proc/sys/vm/overcommit_memory echo 0 > /proc/sys/vm/overcommit_kbytes 看https://www.kernel.org/doc/Documentation/sysctl/vm.txt了解选项的描述。

标准警告适用：当系统内存不足并且您的程序要求更多内存时，它将被拒绝；这是许多程序崩溃或卡住的点。

相关内容