bjo*_*ser 7 mongodb oom-killer
我们在三台机器上运行一个 mongodb 副本集。三台机器都有大约 16GB 但只有 255MB Swap。Swappiness 保留其默认值 60。机器运行 CentOS 6.4。数据库比 16GB 大得多，但这对我们来说没问题。真正的工作集要小得多。
我们面临的问题是主要消耗会耗尽所有可用内存，而不是被 OOM 杀死。我知道这就是 mongodb 管理内存的方式。
服务器被 OOM 杀死后，必须手动重新启动它。
有什么办法可以防止 mongodb 被 OOM 杀死？调整swappiness？增加交换空间？我认为这些设置只会增加 mongod 被杀之前的宽限期。
OOM 杀手不是任何人管理内存的方式；这是 Linux 内核处理致命故障的方式，最后希望避免系统锁定！
你应该做的是：
确保你有足够的交换。如果你确定，仍然添加更多。
实施资源限制！至少对于您希望使用内存的应用程序（如果您不希望它们使用内存甚至更多 - 这些应用程序通常最终会出现问题）。请参阅 shell 中的 ulimit -v（或限制地址空间）命令，并将其放在应用程序启动之前的 init 脚本中。您还应该限制其他内容（例如进程数 -u 等）......这样，当内存不足时，应用程序将出现 ENOMEM 错误，而不是内核给它们不存在的内存，然后疯狂杀死周围的一切！
告诉内核不要过度使用内存。你可以这样做：
echo "0" > /proc/sys/vm/overcommit_memory
甚至更好（取决于您的交换空间量）
echo "2" > /proc/sys/vm/overcommit_memory; echo "80" > /proc/sys/vm/overcommit_ratio
有关更多信息，请参阅关闭过度使用。
这将指示内核在为应用程序提供它并不真正拥有的内存时更加小心（与世界全球经济危机的相似之处令人震惊）
作为最后一荻的手段，如果你的系统除了MangoDB上的一切是消耗品（但请修复上面的第一个两分！）你可以降低它的机会被杀害（甚至是确保它不会被杀死-即使替代通过调整 /proc/$pid/oom_score_adj 和/或 /proc/$pid/oom_score 是挂机机器，没有任何工作）。
echo "-1000" > /proc/`pidof mangod`/oom_score_adj
有关该主题的更多信息，请参阅驯服 OOM 杀手。