1、HMaster

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

     2、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:CMSInitatingOccupancyFraction=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:+CMSInitatingOccupancyFraction 表示年老代内存占用超过此比例即开始做CMS，这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时，

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

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

          3、HQuorumPeer 

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

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

          4、ThriftServer

               同上