HBase宕机事件处理 & JVM GC回顾

实验环境中执行计算任务，计算任务涉及HIVE、Mahout、Hbase bulkload、MapReduce，工作流驱动通过Shell脚本控制，整个任务执行过程涉及基础行为数据160万条，业务数据40万条。

多次执行任务过程中反复随机出现以下各类异常，仅用文字描述，就不拷贝异常现场了，大家各自对号入座：

1.Hbase的Regionserver进程随机挂掉（该异常几乎每次都发生，只是挂掉的Regionser节点不同）

2.HMaster进程随机挂掉

3.主备Namenode节点随机挂掉

4.Zookeeper节点随机挂掉

5.Zookeeper连接超时

6.JVM GC睡眠时间过长

7.datanode写入超时

等等

通过调研分析和调试，发现问题解决需从以下几个方面着手：

1.Hbase的ZK连接超时相关参数调优：默认的ZK超时设置太短，一旦发生FULL GC，极其容易导致ZK连接超时；

2.Hbase的JVM GC相关参数调优：可以通过GC调优获得更好的GC性能，减少单次GC的时间和FULL GC频率；

3.ZK Server调优：这里指的是ZK的服务端调优，ZK客户端（比如Hbase的客户端）的ZK超时参数必须在服务端超时参数的范围内，否则ZK客户端设置的超时参数起不到效果；

4.HDFS读写数据相关参数需调优；

5.YARN针对各个节点分配资源参数调整：YARN需根据真实节点配置分配资源，之前的YARN配置为每个节点分配的资源都远大于真实虚拟机的硬件资源；

6.集群规划需优化：之前的集群规划中，为了充分利用虚拟机资源，NameNode、NodeManager、DataNode，RegionServer会混用同一个节点，这样会导致这些关键的枢纽节点通信和内存压力过大，从而在计算压力较大时容易发生异常。正确的做法是将枢纽节点（NameNode，ResourceManager，HMaster）和数据+计算节点分开。

四、为了解决该问题而实施的各类配置及集群调整

HBase

hbase-site.xml

<name>zookeeper.session.timeout</name>

</property>

<name>hbase.zookeeper.property.tickTime</name>

</property>

<name>hbase.hregion.memstroe.mslab.enable</name>

</property>

<name>hbase.zookeeper.property.maxClientCnxns</name>

</property>

<name>hbase.client.scanner.timeout.period</name>

</property>

<name>hbase.rpc.timeout</name>

</property>

<name>hbase.hregion.max.filesize</name>

</property>

<name>hbase.regionserver.handler.count</name>

</property>

<name>dfs.client.socket-timeout</name>

<description>Down the DFS timeout from 60 to 10 seconds.</description>

</property>

hbase-env.sh

export HBASE_HEAPSIZE=2048M

export HBASE_HOME=/home/fulong/Hbase/hbase-0.98.6-cdh5.2.0

export HBASE_LOG_DIR=${HBASE_HOME}/logs

export HBASE_OPTS="-server -Xms1g -Xmx1g -XX:NewRatio=2 -XX:PermSize=128m -XX:MaxPermSize=128m -verbose:gc -Xloggc:$HBASE_HOME/logs/hbasegc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$HBASE_HOME/logs"

zookeeper

zoo.cfg

syncLimit=10

#New in 3.3.0: the maximum session timeout in milliseconds that the server will allow the client to negotiate. Defaults to 20 times the tickTime.

maxSessionTimeout=300000

# the directory where the snapshot is stored.

# do not use /tmp for storage, /tmp here is just

# example sakes.

dataDir=/home/fulong/Zookeeper/CDH/zookdata

# the port at which the clients will connect

clientPort=2181

修改以下两个文件是为了跟踪ZK日志，ZK的默认日志查看不方便。

log4j.properties

zookeeper.root.logger=INFO,CONSOLE,ROLLINGFILE

zookeeper.console.threshold=INFO

zookeeper.log.dir=/home/fulong/Zookeeper/CDH/zooklogs

zookeeper.log.file=zookeeper.log

zookeeper.log.threshold=DEBUG

zookeeper.tracelog.dir=/home/fulong/Zookeeper/CDH/zooklogs

zookeeper.tracelog.file=zookeeper_trace.log

log4j.appender.ROLLINGFILE=org.apache.log4j.RollingFileAppender

log4j.appender.ROLLINGFILE.Threshold=${zookeeper.log.threshold}

log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file}

# Max log file size of 10MB

log4j.appender.ROLLINGFILE.MaxFileSize=50MB

zkEnv.sh

if [ "x${ZOO_LOG4J_PROP}" = "x" ]

then

ZOO_LOG4J_PROP="INFO,CONSOLE,ROLLINGFILE"

备注：修改完以上两个文件后，并没有如愿的见到ZK的Log4j日志文件，原因待进一步调研。

HDFS

hdfs-site.xml

<name>dfs.datanode.socket.write.timeout</name>

</property>

<name>dfs.client.socket-timeout</name>

</property>

<name>dfs.datanode.max.xcievers</name>

</property>

YARN

yarn-site.xml

<name>yarn.scheduler.minimum-allocation-mb</name>

</property>

<name>yarn.scheduler.fair.user-as-default-queue</name>

<value>false</value>

</property>

<name>yarn.resourcemanager.zk-timeout-ms</name>

</property>

<name>yarn.nodemanager.resource.memory-mb</name>

</property>

<name>yarn.scheduler.minimum-allocation-mb</name>

</property>

<name>yarn.scheduler.maximum-allocation-mb</name>

</property>

<name>yarn.nodemanager.resource.cpu-vcores</name>

</property>

<name>yarn.scheduler.maximum-allocation-vcores</name>

</property>

<name>yarn.nodemanager.container-monitor.interval-ms</name>

</property>

集群调整

NN Active, NN Standby, RM Active, RM Standby 所在节点均不运行DN,NM,RS

DN、NM、RS所在节点一一对应。

调整过后的布局：

说明：如果遇到类似问题，可以重点参考以上配置项，但具体数值请根据具体情况具体分析。

五、补充回顾--JVM GC

调优过程中GC问题十分明显，未调优之前，频繁出现3~6min的Full GC时间，调优过后，GC时间能控制在20s以内。

GC调优对于Hadoop集群十分重要，是必须掌握的基础知识，在此简单记录。

完整知识叙述请参见：

英文原文：http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/

译文地址：http://www.importnew.com/1993.html

以及Oracle网站上的相关说明：

http://www.oracle.com/technetwork/java/javase/tech/exactoptions-jsp-141536.html

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html

以下仅仅描述最重要的基础知识：

每个JVM主要内存区域分为两部分：Permanent Space 和 Heap Space。

Permanent即持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。

Heap={Old+NEW={Eden,Survivor 0 ,Survivor 1}}，Old即老年代（Old Generation），New即年轻代（Young Generation）。年轻代（Young Generation）用来保存那些第一次被创建的对象，它进一步被分为三个空间：一个伊甸园空间（Eden ），两个幸存者空间（Survivor ）。老年代和年轻代的划分对垃圾收集影响比较大。

基本的执行顺序如下：

绝大多数刚刚被创建的对象会存放在伊甸园（Eden ）空间。
在伊甸园（Eden ）空间执行了第一次GC之后，存活的对象被移动到其中一个幸存者空间。
此后，在伊甸园空间执行GC之后，存活的对象会被堆积在同一个幸存者空间。
当一个幸存者空间饱和，还在存活的对象会被移动到另一个幸存者空间。之后会清空已经饱和的那个幸存者空间。
在以上的步骤中重复几次依然存活的对象，就会被移动到老年代。

截止目前版本，Java可配置的垃圾收集器有5种类型：

Serial GC
Parallel GC
Parallel Old GC (Parallel Compacting GC)
Concurrent Mark & Sweep GC (or “CMS”)
Garbage First (G1) GC

其中用得较多比较成熟的是CMS。

我们可以通过各种工具来监控JVM GC情况，比较简单直观的是jstat。比如我们要监控NameNode的GC情况，可以先用jps查看到进程号，然后通过jstat查看gc情况：

jstat -gcutil后面跟的参数是JVM进程号，1s是数据刷新时间。命令输出的每一列依次是：幸存者0的空间占用比例，幸存者1的空间占用比例，伊甸园空间的占用比例，老年代空间的占用比例，持久代空间的占用比例，年轻代（S0+S1+E）发生GC的次数，年轻代发生GC的总时间（秒为单位），FULL GC发生的次数，FULL GC发生的总时间（秒为单位），GC消耗的总时间（秒为单位）。

最后附上我们本次调优hbase设置的JVM参数：

-server //开启java服务器模式

-Xms1g //最小最大堆内存

-Xmx1g

-XX:NewRatio=2 //老年代空间：年轻代空间=2

-XX:PermSize=128m //初始和最大持久代空间，感觉可以进一步缩减，目前观察持久代空间使用没超过30%

-XX:MaxPermSize=128m

-Xloggc:$HBASE_HOME/logs/hbasegc.log //开启gc日志功能，便于调试，基本不会影响性能

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-XX:+UseParNewGC //开启CMS垃圾回收期

-XX:+CMSParallelRemarkEnabled

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=75

HBase宕机事件处理 & JVM GC回顾

相关推荐