【甘道夫】HBase随机宕机事件处理 & JVM GC回顾，甘道夫hbase事件

文章由LinuxBoy分享于2019-03-27 07:03:09热评（27）

【甘道夫】HBase随机宕机事件处理 & JVM GC回顾，甘道夫hbase事件

一、引言 本文记录了困扰团队两周的HBase随机宕机事件的解决方案，并回顾了JVM GC调优基础知识，供各位参考。

欢迎转载，请注明出处： http://blog.csdn.net/u010967382/article/details/42394031

二、实验环境
16台虚拟机，每台4G内存，1核CPU，400G硬盘 Ubuntu 14.04 LTS (GNU/Linux 3.13.0-29-generic x86_64)
CDH5.2.0套装（包括相应版本的Hadoop，HIVE，Hbase，Mahout，Sqoop，Zookeeper等）
Java 1.7.0_60 64-Bit Server

三、异常现场 在以上实验环境中执行计算任务，计算任务涉及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 ）。老年代和年轻代的划分对垃圾收集影响比较大。基本的执行顺序如下：截止目前版本，Java可配置的垃圾收集器有5种类型：其中用得较多比较成熟的是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回顾，甘道夫hbase事件