hbase守护进程及内存调优

一、HMaster

          HMaster的任务前面已经说过了，两个大方向：1、管理Hbase Table的 DDL操做 2、region的分配工做，任务不是很艰巨，可是若是采用默认自动split region的方式，     HMaster会稍微忙一些，负载不大，可适度对此进程作适量放大heap 的操做，但不可太大，由于更耗内存的是HRegionServer

     二、HRegionServer

          这个进程是HBase中的核心守护进程，原则上是每一个slave启动一个HRegionServer,但多种状况可能致使HRegionServer 意外退出，下面举几个简单的方面:

•  

•  网络很差，致使RegionServer 和 HMaster通讯超时，RegionServer被认为已经挂掉，从而退出集群 --网络问题，没法从软件方面解决，关于通讯超时的设置下面作个简单介绍

•  Java full GC ，这个过程会block全部的线程，若是此事件过长，致使Session expired 会话过时，致使退出集群--下文会阐述

•  各节点时间不一致，致使RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默认是30s，但不要太大，毕竟时间不一致是不正常现象，可将全部节点和同一服务器时间作同步，也能够和时间服务器同步。

          第一种状况 和其它缘由致使的RegionServer 超时挂掉的问题，咱们要首先要调高Session的容忍度，默认180000其实这个回话有效期已经够长的了，可是有的集群是能够

   下降了这个值，可能会形成Session 超时，这个参数是 zookeeper.session.timeout 默认18000。

          针对上面这个参数，有的博文认为即便设为180000也不能真正的达到目的，由于zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为

   20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候，系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。

          针对上述观点，我从源码中找到告终论，首先若是是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码：

•  

•           HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ，而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。

•           调用HQuorunPeer.runZKServer

•           调用QuorumPeerMain.runFromConfig

•           设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());

•           由此可看此件并无直接和tickTime对比的机会。却是minSessionTimeout没有设置，默认是2*ticktime

          因而可知 其实若是设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime，再不信能够用echo conf|nc zserver 2181 看一下 zookeeper系统参数

          第二种状况是要讨论的，致使产生这个问题的主要缘由是不少，产生的情景不少，好比在作 major compact的过程当中，时间过长，致使Full GC等，那就尽可能去减小这种情

   况的发生。二个方面

•  

•   适度增大守护进程的HeapSize

•   调整内存回收参数

          第一个方面：Hbase　默认各守护进程为1G  在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000，当咱们启动hbase各守护进程的时候，那全部的hbase守护进程都

     将是1000的heapsize，对于有的进程，够用，但有些进程取远远不够，咱们能够考虑增大此参数，好比export HBASE-HEAPSIZE=6000 那就把守护进程的heap 内存调大到

     6G,可是这样会有问题，有些进程不须要这么多，虽然设置的比较大不影响内存的实际占用，但却混淆了对各进程内存占用的认识。因此上述参数不作改变，在下面的参数中

     修改守护进程Heap 内存。

•  

• export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

•  

• export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC 

                    -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

•  

• export HBASE_THRIFT_OPTS="$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"

• export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"

            咱们分别对各守护进程设置堆内存 其中-Xmx 表示最大可用内存，-Xms表示出事分配内存 -Xmn 表示 年轻代堆内存分配,这个值网上有的建议按照3/3 总heapsize来设

     置，由于是经验值，暂没法考证合理性，更多详细的堆内存分配参数，本地不作过多阐述，后面有机会可作一个单元来解释。那其它参数是什么意思呢?

     -XX：+UseParNewGC 等，这就到了咱们说的第二个方面：

            第二个方面：调整内存回收参数，好比-XX:+UseParNewGC 表示年轻带内存回收策略采用并发收集，此参数在JDK5.0已经自动配置，不需再手动配置；

     -XX:+UseConcMarkSweepGC 表示年老代并发收集；

     -XX:+CMSInitiatingOccupancyFraction表示年老代内存占用超过此比例即开始作CMS，这个参数很重要在JDK 5.0之后此值默认是90 也就是当年老代对内存占用90%以上时，

     才开始作内存收集，而此时剩余的10%依然接受从年轻代迁移过来的对象，迁移过快，致使年老代heap 100%时，Full GC 即开始，才是会暂停全部的任务，直至Full GC 完

     成，此时是形成RegionServer 意外退出的元凶，那为了安全起见，在调大堆内存的状况下 蒋此值下降到一个较低的阀值，减小Full GC的产生，那我建议此值设70%。

          三、HQuorumPeer 

               此守护集成是Zookeeper的守护进程，由于咱们用的是Hbase内置的ZooKeeper 因此此进程启动过程当中，会读取hbase-env.sh 因此守护进程对内存和 HBASE-HEAPSIZE

     的一致，因此也应在hbase-env.sh中合理设置，见HRegionServer 小节中的参数设置方法。

          四、ThriftServer

               同上