Hbase regionserver频繁突然挂掉的问题处理

一、背景

系统：linux centos7.4
Hbase：2.1.0-cdh6.3.2 （CDH版本）

二、现象

1、应用方报错：

Connection refused: hadoop05/ip:16020

2、查看cdh页面

发现HBase的regionserver有4个节点，全部挂掉

三、问题排查

登录机器查看日志，发现两个明显错误和一个奇怪的情况：

1、snapshot超时

2022-11-08 17:50:22,005 INFO org.apache.hadoop.hbase.procedure.ProcedureMember: Received abort on procedure with no local subprocedure vtable.DATA_ZT.CABIN_FIND.1667736700479, ignoring it.
org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable via timer-java.util.Timer@77c0afe2:org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable: org.apache.hadoop.hbase.errorhandling.TimeoutException: Timeout elapsed! Source:Timeout caused Foreign Exception Start:1667736605731, End:1667737205731, diff:600000, max:600000 ms
    at org.apache.hadoop.hbase.errorhandling.ForeignException.deserialize(ForeignException.java:169)
    at org.apache.hadoop.hbase.procedure.ZKProcedureMemberRpcs.abort(ZKProcedureMemberRpcs.java:336)
    at org.apache.hadoop.hbase.procedure.ZKProcedureMemberRpcs.watchForAbortedProcedures(ZKProcedureMemberRpcs.java:145)
    at org.apache.hadoop.hbase.procedure.ZKProcedureMemberRpcs.start(ZKProcedureMemberRpcs.java:360)
    at org.apache.hadoop.hbase.regionserver.snapshot.RegionServerSnapshotManager.start(RegionServerSnapshotManager.java:125)
    at org.apache.hadoop.hbase.procedure.RegionServerProcedureManagerHost.start(RegionServerProcedureManagerHost.java:54)
    at org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:979)
    at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.hadoop.hbase.errorhandling.ForeignException$ProxyThrowable: org.apache.hadoop.hbase.errorhandling.TimeoutException: Timeout elapsed! Source:Timeout caused Foreign Exception Start:1667736605731, End:1667737205731, diff:600000, max:600000 ms
    at org.apache.hadoop.hbase.errorhandling.TimeoutExceptionInjector$1.run(TimeoutExceptionInjector.java:69)
    at java.util.TimerThread.mainLoop(Timer.java:555)
    at java.util.TimerThread.run(Timer.java:505)

2、内存频繁超过高水位watermark

2022-11-08 17:55:22,932 WARN org.apache.hadoop.hbase.regionserver.HeapMemoryManager: heapOccupancyPercent 0.95184726 is above heap occupancy alarm watermark (0.95)
2022-11-08 17:55:24,141 INFO org.apache.hadoop.hbase.regionserver.HeapMemoryManager: heapOccupancyPercent 0.7269536 is now below the heap occupancy alarm watermark (0.95)

3、奇怪的情况：没有正常关闭的日志

每个节点的日志，都是突然停止的。查看进程，已经不在了。

四、原因

1、snapshot尚未找到原因

2、内存频繁超过高水位

结合没有正常关闭的日志，猜测可能是系统内存OOM导致的。
意识查看当前进程，是否有非正常关闭的：

[root@hadoop05 hbase]# jps
31058 Jps
14696 -- process information unavailable
15243 DataNode
13597 NodeManager
12143 Kafka

果真发现process information unavailable字样，代表此进程非正常关闭。
再查看是否是hbase进程（这台机器上只有regionserver这一个hbase进程）：

[root@hadoop05 hbase]# find / -name 14696
/tmp/hsperfdata_hbase/14696

然后根据进程pid，查看系统日志，是否有oom-killer的情况：

[root@hadoop05 hbase]# less /var/log/messges

Nov  9 16:56:41 hadoop05 kernel: Out of memory: Kill process 14696 (java) score 166 or sacrifice child
Nov  9 16:56:41 hadoop05 kernel: Killed process 14696 (java) total-vm:9259984kB, anon-rss:2694204kB, file-rss:0kB, shmem-rss:0kB
Nov  9 16:56:41 hadoop05 kernel: ctcss-agentd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Nov  9 16:56:41 hadoop05 kernel: ctcss-agentd cpuset=/ mems_allowed=0

结果发现，regionserver果真被系统kill掉了

五、解决

1、查看资源情况

发现机器只有16G的内存，上面部署了nodemnager、datanode，nodemanager根据任务运行情况，会占用1-16G内存（也不知道谁配置的，16G的机器，配置的nodemanager container可用最大内存yarn.scheduler.maximum-allocation-mb和yarn.nodemanager.resource.memory-mb都是60G，所以可能占满[当然还要考虑nodemanager所在机器的物理内存使用率超过高水位时候的停止服务问题，所以不会完全占满]），datanode占得不多，也需要分一些。剩余给regionserver的资源其实不多。

2、查看regionserver内存情况

regionserver的heapsize给的是2G，bucketcache是4G，memstore是128M

经过查看机器上的region数量，发现4个regionserver承载了515个region，平均每个rs需要有128个region，这些region都需要至少1个memstore，每个memstore是128M，总共需要16G的内存才能满足这些regoin同时写入需求。而heapsize只给了2G，这也解释了，为什么总是报触及watermark的报错了。

3、综上，得出结论

这里的问题有两个：

1）、yarn配置的资源过高

这个导致yarn有任务跑的时候，会将机器资源占满，而根据系统oom-killer的策略，会将使用内存最高的进程杀掉。map和reduce的内存配置都是0，那么默认会给1g的容器大小。所以，regionserver大约会占2G的ram，可能会占用4-5G的虚拟内存，killer的评分很高，基本每次都被杀掉。

这是主因。

2）、每个rs的region很多

平均每个rs有128个region，那么在普通情况下，2G的heap只能够给16个region的memstore提供内存，而这2G的内存，还要给其他功能使用。所以，经常会出现触及watermark的情况。

4、解决

1）、临时解决办法

将yarn.scheduler.maximum-allocation-mb和yarn.nodemanager.resource.memory-mb设置为8G。避免给yarn分配的内存过多，发生oom-killer。

2）、根本解决办法

终极解决办法：巧妇难为无米之炊，该加资源加资源。
资源充足的情况下，能规避90%的问题。

六、反思与规避

1、部署大数据集群的时候，应先了解清楚业务情况

比如数据量；业务是以实时还是离线为主；业务流程是什么样；业务中间结果数据有多少；实时任务流使用的组件；离线任务流使用的组件等等。
最关键的是要依据以上内容，评估各大数据组件的关键参数。

2、集群依赖的主机资源必须充足

在有些项目的生产环境上，客户对大数据组件使用的资源量有疑问：怎么会用那么多资源？
这时候，直面客户的技术人员一定要讲清楚，争取到最大的资源。否则就会出现如上的问题，资源不足，徒增烦恼。

好记性不如赖笔头。
与君共勉。