mongodb中的oom-killer的问题

from: http://blog.csdn.net/metaxen/article/details/7188689

本文主要内容

• 遇到问题
• 什么是Overcommit和OOM？
• overcommit的策略
• 当oom-killer发生时，linux会选择杀死哪些进程
• 实验
• 结论

遇到的问题

在对mongodb的GridFS进行压力测试时(128M内存，几十个读写进程)，经常触发oom-killer。轻则mongod进程被系统杀死，重则整个系统假死(终端没有反应，SSH可以建立连接，但是登录不上，系统可以ping通)。

什么是Overcommit和OOM

在Unix中，当一个用户进程使用malloc()函数申请内存时，假如返回值是NULL，则这个进程知道当前没有可用内存空间，就会做相应的处理工作。许多进程会打印错误信息并退出。

Linux使用另外一种处理方式，它对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存。这种技术叫做Overcommit。

当内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程)，以便释放内存。

Overcommit的策略

Linux下overcommit有三种策略(Documentation/vm/overcommit-accounting)：

0. 启发式策略。合理的overcommit会被接受，不合理的overcommit会被拒绝。

1. 任何overcommit都会被接受。

2. 当系统分配的内存超过swap+N%*物理RAM(N%由vm.overcommit_ratio决定)时，会拒绝commit。

overcommit的策略通过vm.overcommit_memory设置。
overcommit的百分比由vm.overcommit_ratio设置。

# echo 2 > /proc/sys/vm/overcommit_memory

# echo 80 > /proc/sys/vm/overcommit_ratio

当oom-killer发生时，linux会选择杀死哪些进程

选择进程的函数是oom_badness函数(在mm/oom_kill.c中)，该函数会计算每个进程的点数(0~1000)。
点数越高，这个进程越有可能被杀死。每个进程的点数跟 oom_score_adj有关，而且oom_score_adj可以被设置(-1000最低，1000最高)。

实验

我把mongod的oom_score_adj设置成-1000时，发生oom-killer时，mongod都不会被系统杀死。

我把mongod的oom_score_adj设置成1000时，发生oom-killer时，mongod都首先被系统杀死。

在9:54:44的实验中，没有设置mongod的oom_score_adj的值，其他的都设置为1000。

假如不设置mongod的oom_score_adj的值，则系统可能会杀死mongod或者杀死其他进程。

结论

因此，为了保证mongod触发的oom-killer不会使系统假死，需要设置mongod的oom_score_adj为1000，这样系统只会杀死mongod，而不会杀死其他进程。