前几日，同事收到不少异常报警，发现调用下游一个基础服务大量超时。通过讨论，为了防止服务宕机，咱们把流量入口给拦住（咱们的系统主要是处理上游推下来的Mq消息，就是将Mq消费入口给拦了）。咱们还想着这样就能万事大吉应该不会产生脏数据。默默的等着下游系统解决问题。忽然陆续收到服务宕机，7台核心业务服务器无一幸免全都挂了。java
这时，咱们想找出dump信息，看是否是jvm触发的，结果找了一圈都没有看到相关信息。既然，没有dump信息那确定就不是JVM触发的kill（由于咱们线上服务都开启异常自动dump堆栈的功能）。难道是内核由于内存不足触发的吗？触发日志在哪里能够看到呢？因为头次遇到，只能借助网上的力量，网上说输入 grep 'Out of memory' /var/log/messages。（其实就是在系统日志里面查看是否是能找到内存溢出的相关信息），果真有相似日志，以下图所示： 
linux
可是，日志也看不出来是什么缘由致使的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.网络