记录一次OOM的异常排查过程
记录一次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，否则有再大的盘也不够造啊。:( )
