导语：

近期腾讯云的一家大客户频繁出现HBase regionserver 挂掉，影响业务正常使用。通过调整堆栈大小、gc优化、超时时间等都无法解决该问题。经过细致并综合分析hbase regionserver、hbase master以及 zookeeper的日志，发现了问题所在：tickTime设置导致hbase超时时间错误。

一、故障现象

1、 首先regionserver频繁爆出两类错误：

wal.FSHLog: Error syncing, request close of WAL:

以及出现错误：

regionserver.MemStoreFlusher：Cache flush failed for region XXX ......

2、然后出现regionserver死亡错误：

HBase error : Memstore size is xxxxxx

以及出现regionserver dead 故障：

Region server exiting
java.lang.RuntimeException: HRegionServer Aborted

二、故障分析与解决

从上述报错可以看出，引起regionserver 故障的主要原因集中在memstore，因此首先想到是regionserver 的堆栈设置不合理或者是gc优化不合理。因此，我们将hbase以及regionserver 的堆栈都设置为16G，然后对gc进行优化。最终，HBase具体优化参数如下所示：

export HBASE_HEAPSIZE=16384
export master_heapsize=8192
export regionserver_heapsize=16384
export HBASE_OPTS="$HBASE_OPTS -Xss512k  -XX:PermSize=256m -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:GCPauseIntervalMillis=100 -XX:-OmitStackTraceInFastThrow -XX:MaxTenuringThreshold=1 -XX:ConcGCThreads=12 -XX:G1OldCSetRegionThresholdPercent=3 -XX:ParallelGCThreads=18 -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:G1MixedGCCountTarget=16 -XX:InitiatingHeapOccupancyPercent=75 -XX:G1ReservePercent=5  -XX:G1NewSizePercent=8 -XX:G1HeapRegionSize=16m  -XX:ErrorFile={{log_dir}}/hs_err_pid%p.log"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xmx{{master_heapsize}} -XX:PermSize=256m -XX:MaxPermSize=256m"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:CMSInitiatingOccupancyFraction=70  -Xms{{regionserver_heapsize}} -Xmx{{regionserver_heapsize}}"

经过参数优化之后，regionserver 频繁挂掉的情况有所改善。

但是，regionserver 还是出现了挂掉的情况，只是比之前有改善。因此通过优化堆栈以及gc，并不能完全解决该问题。

三、分析故障原因

既然通过优化hbase本身无法解决regionserver频繁挂掉的原因，那就必须将分析扩大到hbase相关的进程。与hbase密切相关的是zookeeper。我们详细分析看zk的日志，比如之前regionserver在03:03:17时间出现了regionserver dead 报错信息，因此我们分析zk在这个时间段前后的日志。从日志看到regionserver与zk的超时时间是40秒，“the sessions negotiated with zookeeper from dead regionserver were of 40s”。然后再查看regionserver的gc时长，确实超过了40秒。

总结原因：

（1）gc时间过长，超过40秒的maxSessionTimeout时间，使得zk认为regionserver已经挂掉dead；

（2）zk返回dead region到master，master就让其他regionserver负责dead regionserver的regions；

（3）其他regionserver会读取wal进行恢复regions，处理完的wal，会把wal文件删除；

（4）dead regionserver的gc完成，并且恢复服务之后，找不到wal，已经产生上面截图中的报错（wal.FSHLog: Error syncing, request close of WAL）；

（5）dead regionserver从zk得知自己dead，就关闭自己（Region server exiting，java.lang.RuntimeException: HRegionServer Aborted）

四、最终原因：tickTime超时

经过上面的分析，是gc时间超过40秒的maxSessionTimeout导致的regionserver挂掉。但是，我们就很纳闷了，因为我们设置的zookeeper.session.timeout超时时间为240秒，远远超过40秒时间。非常奇怪呀！

经过hbase社区求助，以及google类似的问题，最终找到原因（详细链接，请参考：https://superuser.blog/hbase-dead-regionserver/）：

原来我们的HBase 并没有设置tickTime，最终hbase与zk的会话最大超时时间并不是zookeeper.session.timeout参数决定的，而是有zk的maxSessionTimeout决定。zk会根据minSessionTimeout与maxSessionTimeout两个参数重新调整最后的超时值，minSessionTimeout=2*tickTime, maxSessionTimeout=20*tickTime。我们的大数据集群，zk的tickTime设置为默认值（2000ms）2秒，因此，最终hbase 与 zk的超时时间就为40秒。

经过调整zk的tickTime为6秒，相应的zookeeper.session.timeout为120秒，最终解决regionserver 频繁挂掉的故障。