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

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

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

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

扫描二维码关注公众号，回复： 4339210 查看本文章

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 总结

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

秦凯新于深圳 20181201