☰

MongoDB 遭遇 OOM 终止

tag-icon • tag-icon mongodb oom-killer
MongoDB 遭遇 OOM 终止

我们在三台机器上运行 mongodb 副本集。这三台机器都有大约 16GB 的空间，但交换空间只有 255MB。交换空间保留其默认值 60。这些机器运行的是 CentOS 6.4。数据库比 16GB 大得多，但这对我们来说没问题。实际工作集要小得多。

我们面临的问题是主进程消耗了所有可用内存，然后导致 OOM-Killed。我知道这是 mongodb 管理内存的方式。

服务器因 OOM 而终止后，必须有人手动重新启动它。

有什么方法可以防止 mongodb 因 OOM 而死？调整 swappiness？增加交换空间？我认为这些设置只会增加 mongod 被杀死前的宽限期。

答案1

OOM killer 不是一个办法任何人管理内存；这是 Linux 内核处理致命故障的最后希望，以避免系统锁定！

你应该做的是：

  • 确保你有足够的交换空间。如果你确定的话，还可以添加更多。

  • 实施资源限制！至少对于您预计会使用内存的应用程序（如果您不希望它们使用内存，则更是如此 - 这些通常最终会出现问题）。查看 shell 中的 ulimit -v（或限制地址空间）命令，并将其放在应用程序启动之前，放在其 init 脚本中。您还应该限制其他内容（例如进程数 -u 等）...这样，当内存不足时，应用程序将收到 ENOMEM 错误，而不是内核为它们提供不存在的内存，然后疯狂地杀死周围的一切！

  • 告诉内核不要过度使用内存。你可以这样做：

    回显“0”> /proc/sys/vm/overcommit_memory

    甚至更好（取决于你的交换空间量）

    回显“2”> /proc/sys/vm/overcommit_memory；回显“80”> /proc/sys/vm/overcommit_ratio

    看关闭过度使用了解更多信息。

    这将指示内核在向应用程序提供它实际上没有的内存时要更加小心（与全球经济危机的相似之处令人震惊）

  • 作为最后的手段，如果你的系统上除了 MangoDB 之外的所有东西都是消耗品（但请先解决上述两点！），你可以降低被杀死的可能性（或者甚至确保它不会被杀死 - 即使替代方案是挂断机器而没有任何工作）通过调整 /proc/$pid/oom_score_adj 和/或 /proc/$pid/oom_score。

    echo "-1000" > /proc/`pidof mango`/oom_score_adj

    看驯服OOM杀手了解有关该主题的更多信息。

相关内容