记录一次线上Hbase2.1.0版本RegionServer节点无故挂掉，且无日志输出

记录一次线上 Hbase2.1.0 版本 RegionServer

节点无故挂掉，且无日志输出

环境

问题描述

Hbase上线大半年一直稳定运行，最近发现每天都会有RgionServer节点无故挂点，从日志可以看到

Hbase重启但是后面无任何日志输出。观察到CDH页面上该节点已经下线。

问题解决思路

第一步：查看系统日志

翻遍hbase各种日志均无任何报错信息，那么我们怀疑是不是系统把这个节点给kill掉了呢。接下来我们

查看了系统日志。查看/var/log/message发现问题所在了。

jdk: Oracle jdk-1.8_181

os: CentOS Linux release 7.4.1708 (Core)

hbase: 2.1.0-cdh6.3.0发现hbase的RegionServer的进程ID在刚刚重启的时候就被kill。signal 6 是内存非法操作

由于之前我们将系统生成abrt关闭，所以我们需要修改两个文件，并重启abrt服务，文件所在->

/etc/abrt下的两个文件，分别是：abrt-action-save-package-data.conf 和 abrt.conf，修改内容如下

重启服务

接下来就等下一次hbase的节点挂了之后查看转储文件，转储文件在/var/sqool/abrt下。

第二步 查看转储文件内容

首先要知道转储文件怎么查看,coredump文件。自行百度即可（gbd）

0x00007f475d052860应该有内存非法操作的嫌疑，由于动态链接库没有补全成功目前排查卡到这个上

面了。

看到打印的内容都是和 JDK 相关的我们做了一次尝试，升级个别节点 RG 的 JDK 版本，运行尝试后发现没

有，节点还是会挂。

abrt-action-save-package-data.conf

#OpenGPGCheck = no

#ProcessUnpackaged = yes

abrt.conf

#MaxCrashReportsSize = 0

systemctl restart abrtd 第三步 查看转储文件无果后的排查（重点）

我们后面排查的时候去查看/run/cloudera-scm-agent/process/2325-hbase-REGIONSERVER下是否有

东西

发现有个hs_err_pid15967.log JVM生成的错误日志，那么把这个日志下载查看，返现日志这么写的。

里面的地址和排查转储文件下的出问题的地址完全一致，那么我们可以从这个错误日志下手去解决问

题。接下来把里面的部分内容粘贴出来。

Current thread (0x00007f4758820800): JavaThread "AsyncFSWAL-0" daemon

[_thread_in_Java, id=17396, stack(0x00007f36f0aa3000,0x00007f36f0ae4000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:

0x00007f36bc3dd93a

Stack: [0x00007f36f0aa3000,0x00007f36f0ae4000], sp=0x00007f36f0ae2310, free

space=252k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

v ~StubRoutines::jshort_disjoint_arraycopy

J 13350 C2

org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter$OutputStreamWrap

per.write(Ljava/nio/ByteBuffer;II)V (34 bytes) @ 0x00007f475f113fd1

[0x00007f475f113cc0+0x311]

J 16839 C2

org.apache.hadoop.hbase.ByteBufferKeyValue.write(Ljava/io/OutputStream;Z)I (21

bytes) @ 0x00007f475f4329dc [0x00007f475f432960+0x7c]J 12594 C2

org.apache.hadoop.hbase.regionserver.wal.WALCellCodec$EnsureKvEncoder.write(Lorg

/apache/hadoop/hbase/Cell;)V (27 bytes) @ 0x00007f475ef80414

[0x00007f475ef7fc20+0x7f4]

J 13967 C2

org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.append(Lorg/apac

he/hadoop/hbase/wal/WAL$Entry;)V (137 bytes) @ 0x00007f475eb66d68

[0x00007f475eb662c0+0xaa8]

J 16309 C2

org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.append(Lorg/apache/hadoop

/hbase/wal/WALProvider$WriterBase;Lorg/apache/hadoop/hbase/regionserver/wal/FSWA

LEntry;)Z (219 bytes) @ 0x00007f475f88c3d0 [0x00007f475f88c140+0x290]

J 17900 C2 org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.appendAndSync()V

(225 bytes) @ 0x00007f475f08c5ac [0x00007f475f08c4a0+0x10c]

J 20933 C2 org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.consume()V (474

bytes) @ 0x00007f476024e4c8 [0x00007f476024e2c0+0x208]

J 15973 C2 org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL$$Lambda$57.run()V

(8 bytes) @ 0x00007f475e3d868c [0x00007f475e3d8660+0x2c]

J 16450% C2

java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPo

olExecutor$Worker;)V (225 bytes) @ 0x00007f475e4d3308 [0x00007f475e4d2e80+0x488]

j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5

j java.lang.Thread.run()V+11

v ~StubRoutines::call_stub

V [libjvm.so+0x697a76] JavaCalls::call_helper(JavaValue*, methodHandle*,

JavaCallArguments*, Thread*)+0x1056

V [libjvm.so+0x697f81] JavaCalls::call_virtual(JavaValue*, KlassHandle,

Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321

V [libjvm.so+0x698427] JavaCalls::call_virtual(JavaValue*, Handle,

KlassHandle, Symbol*, Symbol*, Thread*)+0x47

V [libjvm.so+0x71789e] thread_entry(JavaThread*, Thread*)+0x7e

V [libjvm.so+0xa813f3] JavaThread::thread_main_inner()+0x103

V [libjvm.so+0xa8153c] JavaThread::run()+0x11c

V [libjvm.so+0x930198] java_start(Thread*)+0x108

C [libpthread.so.0+0x7e25] start_thread+0xc5

VM Arguments:

jvm_args: -Dproc_regionserver -XX:OnOutOfMemoryError=kill -9 %p -

Djava.net.preferIPv4Stack=true -Xms33285996544 -Xmx33285996544 -Xmx64g -Xms32g -

Xmn6g -Xss256k -XX:MaxPermSize=384m -XX:SurvivorRatio=6 -XX:+UseParNewGC -

XX:ParallelGCThreads=10 -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads=16 -

XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -

XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -

XX:CMSMaxAbortablePrecleanTime=500 -XX:CMSFullGCsBeforeCompaction=5 -

XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError -

XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/tmp/hbase/hbase_hbase

REGIONSERVER-58f025f30c5505722d8dee21c92b9469_pid15967.hprof -

XX:OnOutOfMemoryError=/opt/cloudera/cm-agent/service/common/killparent.sh -

Dhbase.log.dir=/log/hbase -Dhbase.log.file=hbase-cmf-hbase-REGIONSERVER

.log.out -Dhbase.home.dir=/opt/cloudera/parcels/CDH-6.3.0-

1.cdh6.3.0.p0.1279813/lib/hbase -Dhbase.id.str= -Dhbase.root.logger=INFO,RFA -

Djava.library.path=/opt/cloudera/parcels/CDH-6.3.0-

1.cdh6.3.0.p0.1279813/lib/hadoop/lib/native:/opt/cloudera/parcels/CDH-6.3.0-

1.cdh6.3.0.p0.1279813/lib/hbase/lib/native/Linux-amd64-64 -

Dhbase.security.logger=INFO,RFAS

java_command: org.apache.hadoop.hbase.regionserver.HRegionServer start查看日志发现异步WAL问题，AsyncFSWAL-0。于是我们上hbase提了issues并对比了一个和我们类似的

问题，如下：

https://issues.apache.org/jira/browse/HBASE-25628

https://issues.apache.org/jira/browse/HBASE-22539

建议感兴趣的把这个issues看一下

根据上面22539大佬的问题解决，目前得到：用了NettyRpcServer，directByteBuffer被提早释放了，

在刷盘的时候用了已经释放的DBB（directByteBuffer）导致内存访问越界。

我们这边目标把异步WAL改成默认的进行测试。

目前为止没有发现节点再有挂的情况。