mongodb中的oom-killer的问题

本文主要内容
  • 遇到问题
  • 什么是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,而不会杀死其他进程。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值