前几日,同事收到很多异常报警,发现调用下游一个基础服务大量超时。经过讨论,为了防止服务宕机,我们把流量入口给拦住(我们的系统主要是处理上游推下来的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.
来源:oschina
链接:https://my.oschina.net/u/2937247/blog/3193659