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_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:+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
同上