Regionserver 频繁挂掉故障处理实践

2018-01-30 10:42:36来源:https://cloud.tencent.com/developer/article/1030070作者:极客头条人点击

分享
第七城市th7cn

导语:


近期腾讯云的一家大客户频繁出现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 频繁挂掉的故障。


原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。


如有侵权,请联系zhuanlan_guanli@qq.com删除。


编辑于15 小时前


第七城市th7cn

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台