我们在三台机器上运行一个mongodb复制器。 所有三台机器都有大约16GB，但只有255MB的交换。 Swappiness留在默认值60上。机器正在运行CentOS 6.4。 数据库比16GB大得多，但对我们来说没关系。 真正的工作集是小得多。
我们面临的问题是，主要的消耗会吃掉所有可用的内存，而不是获得OOM杀死。 我知道这是mongodb如何pipe理内存的方式。
在服务器得到OOM之后，有人必须手动重新启动它。
有什么办法可以防止mongodb被OOM杀死？ 调整swappiness？ 增加交换空间？ 我认为这些设置只会增加mongod死亡之前的宽限期。
OOM杀手并不是任何人pipe理记忆的方式; 最后希望避免系统死锁是Linux内核的方式来处理致命的故障！
你应该做的是：
确保你有足够的交换。 如果您确定，仍然添加更多。
实施资源限制！ 至less应用程序，你期望会使用内存（甚至更多，如果你不期望他们 – 这些通常最终成为问题）。 请参阅shell中的ulimit -v（或limit addressspace）命令，并在应用程序启动之前将其放在init脚本中。 你还应该限制其他的东西（比如进程的数量等等）…这样，当没有足够的内存的时候，应用程序会得到ENOMEM的错误，而不是内核给他们不存在的内存，然后在周围发生的疯狂的杀死！
告诉内核不要过度使用内存。 你可以这样做：
echo“0”> / proc / sys / vm / overcommit_memory
甚至更好（取决于你的交换空间量）
echo“2”> / proc / sys / vm / overcommit_memory; echo“80”> / proc / sys / vm / overcommit_ratio
请参阅closures超量使用以获取更多相关信息。
这将指示内核在给予应用程序内存时更加谨慎，这种内存并不具备真正的内存（类似于全球经济危机令人吃惊）
作为最后一个手段，如果你的系统上除了MangoDB之外的所有东西都是可消耗的（但是请先修正两点以上！），可以降低被杀死的几率 （或者甚至确保它不会被杀死）是hangup机器没有任何工作）通过调整/ proc / $ pid / oom_score_adj和/或/ proc / $ pid / oom_score。
echo“-1000”> / proc /`pidof mangod` / oom_score_adj
有关该主题的更多信息，请参阅驯服OOM杀手 。