java oom-killer_与oom-killer的亲密接触

10月11日晚上，云平台安排上线。需要通宵工作，这次版本更新的重头戏是需要把一个新的模块部署到线上环境，这个新的模块叫prxdms，用来替换掉原有的dms。

我作为一个涉世未深的运维小青年，就按照部署文档按步骤操作，把新版的prxdmx文件复制粘贴，进程开启，然后把老的dms进程断开，检查进程之后，就去厕所里痛痛快快的释放了一下膀胱括约肌的压力，怒来一泡尿，盘算着如何在剩下的时间里刷刷论坛微博，打打酱油然后回家睡觉。

就在我吹着口哨返回到办公室里，他们却齐齐的瞅我，然后告诉我，线上的设备大面积掉线，后来#ps -ef|grep prxdms一下发现是prxdms没有进程，一致怀疑我是困傻了，没有启动prxdms。

我是很相信我自己的，而且翻阅history也证明了我没有犯低级错误，但是很奇怪，我明明启动了prxdms进程，为什么会自己跳出呢？

查看prxdms自己的日志，无果，只提示断开，没有显示断开原因。然后重新启动prxdms，top一下，果然内存和cpu的数字令人发指，但是新进程启动都会有这么一个过程，然后会慢慢地下降。但是好景没多久，再一次集体进程跳出。what the fuck!!!

然后我就#vim /var/logs/message,发现了如下信息：

可见在00：46分的时候，我的prxdms被干掉了。再看看其他的机器，如图：

厉害了我的哥，直接把zabbix-agent都卡出来了，但是往上一翻，原来在zabbix-agent卡出来之前，predms已经自动跳出了。可见三台机器都是在00:47分的时候，内存暴涨，然后linux杀死了当前内存最大的程序。至于金山云的服务器为什么会在零点47分的时候有一次内存暴涨，那就不得而知了。

而这个情况就是oom-killer，也就是说linux系统会默认的给所有的程序分布一些内存供他们使用，但是这个分布的内存肯定是要大于他们正常的需要内存，这部分内存是属于每个进程的，内核直接回收利用的话比较麻烦，所以内核采用一种过度分配内存(over-commit memory)的办法来间接利用这部分 “空闲” 的内存，提高整体内存的使用效率。一般来说这样做没有问题，但当大多数应用程序都消耗完自己的内存的时候麻烦就来了，因为这些应用程序的内存需求加起来超出了物理内存(包括 swap)的容量，内核(OOM killer)必须杀掉一些进程才能腾出空间保障系统正常运行。

我们先看一下cat /proc/sys/vm/overcommit_memory 值0，可见目前采取的是启发策略，即Overcommit。

/proc/sys/vm/overcommit_memory 的值有3个，分别是0，1和2，具体含义如下：

0. 启发式策略。合理的overcommit会被接受，不合理的overcommit会被拒绝。1. 任何overcommit都会被接受。2. 当系统分配的内存超过swap+N%*物理RAM(N%由vm.overcommit_ratio决定)时，会拒绝commit。overcommit的策略通过vm.overcommit_memory设置。overcommit的百分比由vm.overcommit_ratio设置。

而云主机的配置本身就不会很高，而且像oracle、mysql、java这种程序又特别的吃内存，所以这两就是oom-killer的重灾户。

那么遇到这种情况怎么办？第一个方案掏钱升级内存大小，第二个方案就是更换体积更小的程序，或者是优化内存，如果前两个都不好使，那么就动点手脚，调整进程内存参数，不让他们过早的被oom发现，让oom先kill掉其他的进程。

这里主要说的是第三个方案，也就是动手脚。

每一个进程都有一个自己的进程号，即pid。linux是“一切皆文件”的系统，那么我们的pid文件就会出现在/proc/pid号码中。我们以一个zabbix_agent为例：

在/proc会对应每一个进程，有一个pid号码的文件夹，而这个文件夹里面又有很多文件，我们关注的就是这个oom_score的文件。这个数字是可以被我们手动通过oom_score_adj去调整的，而这个数字越小的话，进程被oom_kill的优先级越低，最小值是-1000，最大值是1000。

当然，如果对于脾气比较急的同学，可以直接把oom-killer这个项目干掉，干掉的方法如下：

但是，这个方法严重不推荐于生产环境...

还有，如果机器频繁出现oom-killer的话，那么就只能砸钱提升内存了，这一点是逃不掉的。反正花的也是老板的钱儿，你不用心疼。

［参考资料］

本文转自 苏幕遮618 51CTO博客，原文链接:http://blog.51cto.com/chenx1242/1861667