HBase阻塞急救与朱丽叶暂停线上环境解决方案-OLAP商业环境实战

本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址：1120746959@qq.com，如有任何学术交流，可随时联系。

网上的Hbase调优资料参差不齐，实在是不忍卒读，有些都是拼凑且版本过时的东西，我这里决定综合所有优质资源进行整合，写一份最全，最有深度，不过时的技术博客。辛苦成文，各自珍惜，谢谢！版权声明：禁止转载，欢迎学习，侵权必究！

1 阻塞急救（锦囊妙计）

如果服务器数据出现频频无法写入，RegionServer频频宕机，那么就需要认真分析如下问题，按照优先级进行参数调优：

• RegioneServer 内存设置的太小

  RegioneServer Heap默认值是1GB，那么Memstore默认是占用40%,，才只占用40%，也就是400MB，因此很容易发生阻塞。 解决方案是，在conf/hbase-env.sh中设置：

  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xms8g -Xmx8g"

• HFile 达到允许的最大数量

  hbase.hstore.blockingStoreFile是杀手锏利器，默认值是7，当Store中的HFile数量达到这个数量的时候就会阻塞MemStore刷写动作，注意这里不会阻塞写入请求。用户层是感觉不到的，建议调大。

• memstore 大小达到阈值

  hbase.hregion.memstore.flush.size 默认阈值是128MB

  hbase.hregion.memstore.block.multiplier:是一个倍数，默认是4。

  上面两个数的乘积默认为512M，因为MemStore的刷写存在一个定期检查时间，在下一次刷写检查到来之前若达到了这个阈值，就会立即触发刷写，同时阻塞住所有的写入该Store的写请求。

  解决方案，可以适当调大该参数，问题往往出现在前两个参数上。

• RegionServer上的Memstore总大小达到阈值

  hbase_heapsize(Regionserver 占用堆内存大小)*hbase.regionserver.global.memstore.size 表示全局的Memstore总大小，其中hbase.regionserver.global.memstore.size是一个0-1的数字，代表了memstore在RegionServer上可以占用的百分比，默认是0.4.默认的BlockCache是0.4，加起来就是0.8了。注意在调整memstore的同时，应该调小BlockCache的大小。负责RegionServer估计都启动不起来。

3 朱丽叶暂停

原因主要是Zookeeper惹的祸，在RegionServer发生FULL GC的时候，STW期间太长，被ZK标记为宕机，当RegionerServer GC完成后，苏醒了发现被标记为宕机了，这时候RegionerServer GC就自杀，防止脑裂发生。醒来再自杀，朱丽叶暂停，哈哈！

• RegioneServer 内存设置的太小（灵丹妙药）

  RegioneServer Heap默认值是1GB，那么Memstore默认是占用40%,，才只占用40%，也就是400MB，因此很容易发生阻塞。 解决方案是，在conf/hbase-env.sh中设置：

  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS  -Xms8g -Xmx8g"
  复制代码

• 调整Zookeeper客户端与RegioneServer超时时间设置

  首先调整hbase-site.xml：

  zookeeper.session.timeout 默认值是90000ms也即90s
  复制代码

  其次是Zookeeper内部的conf/zoo.cfg中的tickTime，这个配置文件可以设置为：

  tickTime=2000 即2s  
  复制代码

  通过tickTime计算出

  minSessionTimeout=2*tickTime=4s, maxSessionTimeout=20*tickTime=40s
  复制代码

  因此：

  zookeeper.session.timeout<minSessionTimeout，那么最终SessionTimeout就是minSessionTimeout zookeeper.session.timeout>maxSessionTimeout，那么最终SessionTimeout就是maxSessionTimeout

  因此，tickTime才是最终的决策者。

• GC的回收机制

  如果你的RegionServer内存大于32GB，建议使用G1GC策略，因为G1Gc会把堆内存划分为多个Region,然后对各个Region单独进行GC,这样整体的Full GC 可以被最大限度地避免。另外通过设置MaxGCPauseMillis最大暂停时间，避免时间太长RegionServer自杀。

  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS  -Xms8g -Xmx8g  -XX:+UseG1GC
  -XX:+MaxGCPauseMillis=100"
  复制代码

  如果你的RegionServer内存小于4GB，就不需要考虑G1GC策略了，直接使用

  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS  -Xms8g -Xmx8g  -XX:+UseParNewGC
  -XX:+UseConcMarkSweepGC"
  
  或者大于4G小于32G时：
  
  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS  -Xms8g -Xmx8g  -XX:+UseParNewGC
  -XX:+UseG1GC"
  复制代码

• MLSB内存管理策略开启和参数配置：

默认是开启的，但是并没有分配chunk。每1 GB大小的堆内存做一次Full GC需要8-10秒，如果是32GB，就需要4.2-5.3分钟。这几乎是无法避免的。参数设置如下：

hbase.hregion.memstore.mslab.enabled:设置为true，即打开MSLAB，默认是true。
  hbase.hregion.memstore.chunkpool.maxsize:表示在整个Memstore可以占用的堆内存的比例。默认值是0，因此设置大于0,才算真正开启MSLAB.
  hregion.memstore.chunkpool.initialsize:表示在RegionServer启动的时候预分配一些chunk出来。也是一个比例值，该值表示预分配的chunk占用总的chunkpool的大小。
复制代码

4 总结

本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址：1120746959@qq.com，如有任何学术交流，可随时联系。

阻塞问题和朱丽叶暂停问题是两大范畴的事情，按照优先级进行参数优化，既可以得到最合适的效果。

秦凯新 于深圳 20181201