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=2 -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=75 -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挂掉的好不是么？
示例：
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=70 -XX：+UseCMSInitiatingOccupancyOnly"