调优region server还是master

需要为region server增加参数，而master并不会是个问题，因为它并不处理大负载，数据并不通过它。调优参数只需要加到region server。

region server压力

大量的workloads导致jre支持region server并不是很好，特别是写特别重的情况。需要指定jre参数使得gc策略更适合大量的workloads。

对于写很重的情况，内存中频繁的创建和丢弃不同大小的对象。当数据收到内存buffer中，需要保持到flush达到size自后写到硬盘，new一个store file。（hbase.hregion.memstore.flush.size，或表级别的flush size，表属性或代码）
所以在写入到硬盘之前，这些数据会大量的占用Java heap。需要看是否被快速flush，则影响到数据在heap的新生代就被处理，还是会被移到老年代。

调优新生代heap

可以设置gc options在 hbase-env.sh中， HBASE_OPTS或HBASE_REGIONSERVER_OPTS。后面的只影响到region server，不会作用于master。
（-XX:MaxNewSize=128m -XX:NewSize=128m 等于 -Xmn128m）

如果新生代heap较低，可能会发现CPU load增长，因为会花费大量cpu时间用于新生代的minor gc。

输出gc log

建议输出gc的log。观察concurent mode failure或者promotion failed，将导致程序长时间停顿
（-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log）
要注意这个log并不roll，需要定时手动处理。

GC种类

建议的GC种类：
（-XX:+UseParNewGC and -XX:+UseConcMarkSweepGC）
这里要考虑minor gc和full gc的程序停顿时间，如果超过了zk timeout，这个server会被认为lost。当gc结束了会被通知已经从集群移除，并把自己关机。
CMS会尽量避免full gc，除非出现promotion error，会导致stop world执行full gc。

CMS还有额外选项，是个百分比，控制CMS何时启动，需要避免设置导致 concurrent mode failuer。
（-XX:CMSInitiatingOccupancyFraction=70）
这个比例设为70%，略微大于region server设置的60% heap usage（默认20% block cache和40% memstore的限制）。这样CMS启动会尽量早又不会太频繁。（所以当调优block cache和memstore size时，要响应调整CMS的启动百分比。）

最佳实践例子

export HBASE_REGIONSERVER_OPTS="-Xms8g -Xmx8g -Xmn128m -XX:UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PringtGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log"

关于buffer和memstore

从老年代取出buffer的数据flush到硬盘的时候，会导致老年代的内存空间留下一个非压缩的内存空间，所以规定固定大小的数据去flush，会有利于这个空间的连续利用，避免了需要压缩时导致的full gc出现。但同时也会有heap使用上的浪费，不能完全利用好所有小空间。
（hbase.hregion.memstore.mslab.enabled）默认true
（hbase.hregion.memstore.mslab.chunksize）默认2mb
（hbase.hregion.memstore.mslab.max.allocation）默认256KB，上界，超过则会直接处理，如果很多超过上界会导致更早的gc停顿。

如果仍然会有长时间的gc停顿，建议收集gc的规律，并针对性的做出server的几天或者几周的重启计划。

需要知道，buffer会比directly的KeyValue慢一些。

JAVA heap