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

<property>

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

        <value>300000</value>

</property>

 

<property>

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

        <value>60000</value>

</property>

 

<property>

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

        <value>true</value>

</property>

 

<property>

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

        <value>10000</value>

</property>

 

<property>

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

<value>240000</value>

</property>

 

<property>

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

<value>280000</value>

</property>

 

<property>

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

<value>107374182400</value>

</property>

 

<property>

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

<value>100</value>

</property>

 

<property>

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

<value>300000</value>

<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"

fi

 

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

---

---

HDFS

---

---

hdfs-site.xml

<property>

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

        <value>600000</value>

</property>

 

<property>

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

        <value>300000</value>

</property>

 

<property>

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

        <value>4096</value>

</property>

---

---

YARN

---

---

yarn-site.xml

<property>

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

<value>512</value>

</property>

 

<property>

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

<value>false</value>

</property>

 

<property>

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

<value>120000</value>

</property>

 

<property>

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

<value>3072</value>

</property>

 

<property>

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

<value>128</value>

</property>

 

<property>

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

<value>3072</value>

</property>

 

<property>

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

<value>1</value>

</property>

 

<property>

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

<value>1</value>

</property>

 

<property>

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

<value>300000</value>

</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 ）。老年代和年轻代的划分对垃圾收集影响比较大。

 

        

      基本的执行顺序如下：

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

 

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

 

1. Serial GC
2. Parallel GC
3. Parallel Old GC (Parallel Compacting GC)
4. Concurrent Mark & Sweep GC  (or “CMS”)
5. 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