HMaster 没有处理过重的负载,并且实际的数据服务不经过 HMaster,它的主要任务有2个:一、管理Hbase Table的 DDL操作, 二、region的分配工作,任务不是很艰巨。

但是如果采用默认自动split region的方式,HMaster会稍微忙一些,负载不大,可适度对此进程做适量放大heap 的操作,但不可太大。

  RegionServer在写入数据时,数据会先保存在memstore 中,当大于阈值时候,再写入到磁盘。因为写入的数据是由客户端在不同时间写入的,故而他们占据的Java堆空间很可能是不连续的,会出现孔洞,所以需要调整垃圾回收机制。

RegionServer的新生代大小在128M~512M,老生代大小在几GB。最初写入的数据会保存在新生代,再刷写到磁盘;当数据刷写到磁盘的速度较慢时候,新生代中的数据停留时间过长,会被移到老生代。

新生代空间可以被迅速回收,对内存管理没有影响;老生代数据量大,回收慢,对内存管理影响大。所以二者需要不同的垃圾回收策略。

JVM设置  

进入conf目录,修改hbase-env.sh文件

vi hbase-env.sh

修改HBASE_OPTS属性值:

$HBASE_OPTS -Xmx3g -Xms3g -Xmn512m -Xss256k -XX:MaxPermSize=256m -XX:SurvivorRatio= -XX:MaxTenuringThreshold= -XX:CMSInitiatingOccupancyFraction= -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:-DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log

配置解读:

-Xmx3g           最大堆内存3g

-Xms3g           初始堆内存设置与最大堆内存一样大。如果Xms设置得比较小,当遇到数据量较大时候,堆内存会迅速增长,当上升到最大又会回落,伸缩堆大小会带来压力。

-Xmn512M      新生代512M。新生代不能过小,否则新生代中的生存周期较长的数据会过早移到老生代,引起老生代产生大量内存碎片;新生代也不能过大,否则回收新生代也会造成太长的时间停顿,影响性能。

-XX:CMSInitiatingOccupancyFraction=75     初始占用比为75%的时候开始CMS回收。此值不能太小,否则CMS发生得太频繁。此值不能太大,否则因为CMS需要额外堆内存,会发生堆内存空间不足,导致CMS 失败。

-Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log     写入日志

-XX:+UseParNewGC

新生代采用 ParallelGC 回收器。ParallelGC 将停止运行Java 进程去清空新生代堆,因为新生代很小,所以停顿的时间也很短,需几百毫秒。

-XX:+UseConMarkSweepGC

老年代采用CMS回收器(Concurrent Mark-Sweep Collector) .  CMS 在不停止运行Java进程的情况下异步地完成垃圾回收,CMS会增加CPU的负载,但是可以避免重写老年代堆碎片时候的停顿。老年代回收不可使用 ParallelGC  回收                                                              机制,因为老生代的堆空间大,ParallelGC会造成Java进程长时间停顿,使得RegionServer与ZooKeeper的会话超时,该RegionServer会被误认为已经奔溃并会被抛弃。

对于老年代来说, 它可以更早的开始回收。当分配在老年代的空间比率超过了一个阀值,CMS 开始运行。如果 CMS 开始的太晚,HBase 或许会直接进行 full garbage collection。这种情况会导致block所有的线程,如果这个时间过长,就会导致hbase连接超时,结果就是regionserver集体下线。这是不能容忍额。为了避免这种情况的发生,我们建议设置 -XX:CMSInitiatingOccupancyFraction JVM 参数来精确指定在多少百分比 CMS 应该被开始,正如上面的配置中做的那样。在 百分之 60 或 70 开始是一个好的实践。当老年代使用 CMS,默认的年轻代 GC 将被设置成 Parallel New Collector。
        再来看看hbase为什么可能进行full gc,如果我们不配置-XX:CMSInitiatingOccupancyFraction,jdk1.5以后会使用默认值90%,那么很可能,当老年代内存占用超过分配给他的内存大小的90%,会进行CMS(老年代的回收),但是不会阻止年轻代到老年代的迁移,如果迁移过快,CMS较慢,会出现老年代内存使用率100%,这时会导致full gc。如果我们把这个参数调整小一点,那么能给年轻带到老年代迁移的同时做CMS时一些时间,也就减少了full gc的发生。当然这可能会频繁的gc,但总比整个hbase挂掉的好不是么?

示例:

HBase管理与监控——内存调优-LMLPHP

Master和RegionServer单独配置:

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2g -Xms2g -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn1g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction= -XX:+UseCMSInitiatingOccupancyOnly"
05-27 04:19