HBase RegionServer异常退出问题分析

Posted 2021-04-19 ShuffleFamily

上一篇文章，我们分析了HBase的Split机制，这一篇将分享HBase RegionServer异常退出的问题分析，将介绍如何通过调整RegionServer的GC参数来解决RegionServer异常退出的问题。

1. 背景

我们在维护HBase集群时遇到RegionServer异常退出的问题，分析出现异常退出的RegionServer的日志，发现如下现象：HBase RegionServer由于GC等原因Stop World超过40s（与Zookeeper配置有关），RegionServer在Zookeeper上创建的临时节点由于超时被删除，造成Master认为RegionServer已经下线，重新分配该RegionServer上的Region。待RegionServer恢复后，由于种种原因（如：WAL被删除），只能主动退出。

由分析日志可知，RegionServer异常退出的主要原因是GC持续的时间过长。因此，优化RegionServer的GC参数是解决问题的关键。

2.  问题解决

RegionServer使用16G堆大小，开启了CMS GC。原GC参数如下：

HBASE_HEAPSIZE：16G -XX:+UseConcMarkSweepGC：设置年老代为并发收集 -Xmx16G -Xms16G：-Xms、-Xmx 相等以避免在GC 后调整堆的大小。 -Xmn1G：指定New Generation的大小, Yong区设置过大GC时间长。 -XX:PermSize=128M  -XX:MaxPermSize=256M -XX:SurvivorRatio=8：设置堆内存年轻代中Eden区与Survivor区大小的比值 。设置为8，则两个Survivor区与Eden区的比值为2:8，每个Survivor区占 整个年轻代的1/10。

通过分析GC日志，发现以下现象：1、CMS GC有可能在老年代被使用超过90%时才发生；2、绝大多数情况下，老年代的内存剩余空间大于promotion的内存大小；3、耗时较长的GC往往发生在promotion failed和concurrent mode failure发生时，可能触发了Serial Old GC。如图1，老年代使用达到了90%，此时发生promotion failed和concurrent mode failure。

图1：异常节点的GC日志

我们知道，promotion failed发生在JVM进行Minor GC时，survivor space剩余空间不够，需要提升对象到老年代，而此时老年代没有足够连续空间；concurrent modefailure发生在执行CMS GC的过程中，有对象要放入老年代，而此时老年代连续空间不足。

经过以上分析，结论如下：1、存在老年代剩余空间不足的情况，需要调整相关参数，提前（老年代使用70%时）发生CMS GC；2、有可能是promotion的内存较大，而老年"连续内存空间"不够。据此，GC参数做出如下调整：

-XX:CMSInitiatingOccupancyFraction=70：表示年老代空间到70%时就开始执行CMS，确保年老代有足够的空间接纳来自年轻代的对象。 -XX:+UseCMSInitiatingOccupancyOnly：使用CMSInitiatingOccupancyFraction的值作为old区的空间使用率限制来启动CMS垃圾回收。 -XX:+UseGCLogFileRotation  -XX:NumberOfGCLogFiles=3 -XX:GCLogFileSize=128M:GC日志rotate -XX:+UseParNewGC：设置年轻代为并发收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。 -XX:+CMSParallelRemarkEnabled：并发标记，降低标记停顿，1.6以上默认true。 -XX:+UseCMSCompactAtFullCollection：设置在FULL GC的时候，对年老代的压缩；CMS是不会移动内存的， 因此， 这个非常容易产生碎片， 导致内存不够用， 因此， 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯。可能会影响性能,但是可以消除碎片 。 -XX:CMSFullGCsBeforeCompaction=0：这个参数，指定进行多少次full GC之后，进行内存空间压缩，0是每次都会。

调整前RegionServer异常退出的问题2~3天出现一次，调整后再未出现。观察RegionServer的GC日志，内存整理造成的影响也不明显。