记一次OOM Killer导致的生产事故

过程：

重启服务端某测试服务时，服务器内存配置大，导致系统内存溢出，服务重启失败，继续启动正常，但一核心程序被kill，且未察觉。

原因：系统内存溢出时导致系统触发oom killer，核心程序被优先杀死。

排查过程：

1. 检查被杀死程序日志，无异常（包括）。

2. 检查linux 系统日志：/var/log/messages ,这里会记录进程操作日志。

egrep -i 'killed process' /var.log.messages

注意：该文件只会记录近2天左右的日志

3. 发现有记录，触发过oom killer。

oom killer简析：

1. 给进程分配内存时发现内存不够会触发 oom killer

2. oom killer 会根据现有进程的综合评分进行kill，评分越高的越先被触发。

评分在对应线程的目录下查看：cat /proc/${PID}/oom_score

3. 我们可以通过修改 /proc/${PID}/oom_score_adj 来控制oom_score的值：oom_score的实际值是会在系统计算完成之后在加上oom_score_adj 来定的，可通过以下命令来设置oom_score_adj 从而减低oom_score值。

echo -20 > /proc/28530/oom_score_adj

注： -20 为动态值，可调整

解决方法：

1. 调整程序启动内存分配值，尽量留出富余。

2. 核心程序建议减低oom_score，避免被优先kill掉。

3. 我们也可以完全关闭OOM killer，但不推荐用在生产环境下关闭，执行如下操作：

[root@hadoopgateway ~]#sysctl -w vm.overcommit_memory=2

[root@hadoopgateway ~]# echo "vm.overcommit_memory=2" >> /etc/sysctl.conf

vm.overcommit_memory有0、1、2三个可选值，分别代表如下含义：

0：表示用户申请内存的时候，系统会判断剩余的内存多少，如果不够的话那么就会失败。

1： 用户申请内存的时候，系统不进行任何内存是否够用的检查，直到使用内存超过可用内存。

2： 用户一次申请的内存大小不允许超过可用内存的大小。

通过设置这个参数，即可达到关闭OOM killer，但是一般情况下不建议这么做，毕竟内存持续占用的场景不是很多，或者可以设置/proc/sys/vm/overcommit_memory为0，一般默认就是0，这样可以最大限度的避免系统触发OOM Killer。