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