java进程被kill_java进程被内核kill的分析

前几日，同事收到很多异常报警，发现调用下游一个基础服务大量超时。经过讨论，为了防止服务宕机，我们把流量入口给拦住(我们的系统主要是处理上游推下来的Mq消息，就是将Mq消费入口给拦了)。我们还想着这样就能万事大吉应该不会产生脏数据。默默的等着下游系统解决问题。突然陆续收到服务宕机，7台核心业务服务器无一幸免全都挂了。

这时，我们想找出dump信息，看是不是jvm触发的，结果找了一圈都没有看到相关信息。既然，没有dump信息那肯定就不是JVM触发的kill(因为我们线上服务都开启异常自动dump堆栈的功能)。难道是内核因为内存不足触发的吗？触发日志在哪里可以看到呢？由于头次遇到，只能借助网上的力量，网上说输入 grep 'Out of memory' /var/log/messages。(其实就是在系统日志里面查看是不是能找到内存溢出的相关信息)，果然有类似日志，如下图所示：

但是，日志也看不出来是什么原因导致的kill啊。想着上下翻动日志，看不懂。这个时候又只能借助网络。网上说内核触发了kill也可以通过 dmesg 命令查看(该命令是记录开机启动信息的)。通过现学，发现其实在上图的那条日志前面还保存了，内核kill进程之前的内存占用情况。如下图所示：

这是在图中找到了答案，系统总内存是8G，而filebeat(架构组的日志采集工具)占用2个多G，java进程占用4个多G(大小取上图RSS列，这里代表的是有多少个pageCache，liunx每pageCache等于4kb。所以就是pageCache * 4kb)。系统杀掉了java进程(就是linux内核的OOM Killer杀掉的)。但是为什么进程不杀filebeat进程，而是杀java进程呢？其实这里系统自己有个算分算法(基础分+系统根据内存情况自动打分 ，存放目录在：/proc/pid/oom_score)，OOM Killer会找到等分最高的杀掉。我们可以手动修改每个进程的基础分(-1000到1000，默认是0，存放目录：/proc/pid/oom_score_adj)。其实架构组已经将基础分调整到100了。但是系统打分还是太低了。所以就杀掉了java进程。图一可以看到，java进程的得分是 578 分。现在我们把filebeat的基础得分调成了 999。希望下次如果有类型情况发生先kill filebeat的进程

上面只分析了，为什么总是杀掉的Java进程。但是，为什么filebeat会占用如此大的内存，通常filebeat的内存大小也就在300M左右，这次突然上了2G。这个现象很奇怪。其实filebeat有两个因素直接影响内存占用情况，1.是日志大小 2.是filebeat处理日志时配置的queue大小。我们的系统恰恰是这两个原因导致的，1.调用下游系统超时，所以产生了很多堆栈日志。2.没有指定队列大小，默认是2048.