美文网首页
记录一次OOM的异常排查过程

记录一次OOM的异常排查过程

作者: JackyYin | 来源:发表于2017-07-07 23:58 被阅读0次

记录一次OOM的异常排查过程

现象

最近在规模测试基于AKKA的告警组件时,发现系统运行一段时间后会发生某节点从集群中退出的情况。查看集群管理节点的日志会发现其探测到某节点不可用,按照预先设计的规则,超过一段时间后会自动把该节点设为Down。但是事后看被Down掉的节点进程还在,与集群的网络连接也很正常,根据之前的经验怀疑是GC时间过长,导致与集群的心跳不正常,于是查看gc的日志,果然发现在被设置为Down之前,发生了FullGC,持续时间很长。现象有点奇怪,我们的实现里并没有存储一些大的集合,理论上不应该出现FullGC。

排查

之前的JVM启动参数里面没有开启自动dump的选项,查找JVM参数发现有几个选项可以进行自动dump:HeapDumpOnOutOfMemoryError, HeapDumpBeforeFullGC, HeapDumpAfterFullGC. 最开始的想法是在FullGC之前来查看,因此没加思索就选择了HeapDumpBeforeFullGC(导致了血案发生),重启进程后,就拿了板凳用jvisualvm一直在监控该进程,结果等了一下午也没再发生,heap大小始终保持在4g左右,晚上下班前也未把这个参数关掉,第二天一来就被同事告知这个节点所在的服务器磁盘满了,登陆之后发现,磁盘被N个heap dump文件直接塞满了,进程从晚上12点开始一直在持续Full GC,因此产生了N个dump文件,直到磁盘被塞满挂掉。我原以为heap dump会自动覆盖前面一个,结果却不是,因为这个服务器上还跑了kafka等其他服务,因为磁盘原因,一并给挂掉了,悲剧。

闲言少叙,拿到dump文件后,利用MAT解析,生成报告,经过了漫长的等待,在这个过程中发生了一次MAT因为内存不够而退出,所以要记得把MAT的启动参数里面的最大内存调到足够大,如果有条件可以调到和dump文件差不多大小,不过一般情况下调到dump文件大小的2/3应该够用了。

从下面的overview来看,8G的heap,被akka.dispatch.Dispatcher占掉了7.7G,很显然这就是罪魁祸首。

屏幕快照 2017-07-07 下午6.07.47.png

继续看suspect report,MAT功能很强大,直接给出的suspect报告一般还是比较有参考意义

屏幕快照 2017-07-07 下午7.04.05.png

不过到底是怎么导致这个结果发生的呢,是哪类消息塞满了Dispatcher呢?打开dominator_tree视图,可以非常清楚的看到Dispatcher内部是一个UnboundedMailbox(默认的akka mailbox类型),其底层是一个ConcurrentLinkedQueue,展开后发现基本上每个Node存储的都是GenericMetric对象,至此问题的原因基本清楚了,发生FullGC的这个节点是集群中角色为Worker的节点,其负责接受由路由节点发过来的GenericMetric类型的消息,从Heap来看是接收后的处理速度小于接收的速度,造成了Mailbox的消息堆积,最终导致了FullGC和OOM的发生。

屏幕快照 2017-07-07 下午6.13.45.png

解决方案

其实这个问题的本质开始反映了跨进程的消息流如何处理Back Pressure的问题,流处理上的两个处理环节的速度不一致导致下游有数据积压导致的。解决这个问题要么需要引入Back Pressure控制机制,能够自动调节上下游速度,要么就是要在系统稳定性以及数据丢失之间有所取舍(例如把接收端的akka mailbox改为Bounded类型,这样当超出队列长度时,会有数据丢失但是不会导致oom)。因为在当前系统中不只是数据简单的转换,中间需要按照某些规则进行数据路由以及聚合,所以无法简单采用Spark或者Flink这种自带Backpressure的流框架,因此采用了改变Mailbox类型以及增加worker节点数的方式,通过增加worker节点来提高处理能力,达到上下游的速度匹配来解决了这个问题,同时增加关于DeadLetter消息的监控,当处理能力不足时可以及时发现,不过如果上游的消息输入速度如果不确定时,则无法通过这种方式来解决问题。当前系统是基于akka构建的,其分布式能力非常强大,可以构建弹性的系统,目前基于akka之上的akka stream也日趋稳定和完善,其本身就是自带Back Pressure控制,且其运行不依赖任何额外的第三方框架,属于库级别支持(另外一个流框架库为kafka stream),不过其还未原生支持分布式的能力,只能通过和actor的集成来实现分布式的效果,不过其提供的流式DSL功能非常强大,很有吸引力,值得仔细研究。

最后

最后一点,一定要记得开启HeapDumpOnOutOfMemoryError这个选项,这个只会生效一次,也就是只会生成一个dump,不会把磁盘爆掉。很多生产问题有时不好浮现,这个时候如果能有一份完整的dump文件会帮助极大。此外千万不要在没人的情况下开启HeapDumpBeforeFullGC 或者 HeapDumpBeforeAfterGC,否则有再大的盘也不够造啊。:( )

相关文章

  • 记录一次OOM的异常排查过程

    记录一次OOM的异常排查过程 现象 最近在规模测试基于AKKA的告警组件时,发现系统运行一段时间后会发生某节点从集...

  • 再一次oom的记录

    上一次oom的记录在一次排查OOM的总结,这次oom的排查大概花了一天不到,和leader一起,我这边主要是根据后...

  • [翻译]Java 6,7,8中的String.intern

    前言 最近一直在关注“故障排查”的相关知识,首先着手的是OOM的异常。OOM异常通常会有Perm区的OOM(jav...

  • 记一次jvm堆外内存OOM的解决过程

    本文记录一次堆外内存OOM的排查过程。周末的时候同事对线上服务进行了一次扩容,本以为只是简单增加几个实例而已,结果...

  • OOM 和 FGC异常排查

    概述 OOM: JVM一般都是先尝试GC,GC以后仍然无法腾出空间给新对象的时候才会针对对应线程触发OOM 另外O...

  • 记录一次Flink作业异常的排查过程

    本文来自: PerfMa技术社区PerfMa(笨马网络)官网 最近2周开始接手apache flink全链路监控数...

  • 记录一次Flink作业异常的排查过程

    最近2周开始接手apache flink全链路监控数据的作业,包括指标统计,业务规则匹配等逻辑,计算结果实时写入e...

  • Android TP 触摸异常分析

    近期多台设备出现触摸异常情况,借此记录Android 触摸异常排查解决过程。此篇将介绍通过Android开发者选项...

  • 排查WriteAbortedException异常过程

    昨天突然收到运维信息说线上写日志太猛,磁盘饱满了,然后应用接口超时报警.....一系列问题突然涌现出来.....

  • OOM排查

    http://ifeve.com/one-java-oom/

网友评论

      本文标题:记录一次OOM的异常排查过程

      本文链接:https://www.haomeiwen.com/subject/bkxrhxtx.html