HBase阻塞急救與朱麗葉暫停線上環境解決方案-OLAP商業環境實戰

HBase OLAP · 發表 2018-12-01 16:44:53

摘要：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。網上的H...

本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。

網上的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 總結

阻塞問題和朱麗葉暫停問題是兩大範疇的事情，按照優先順序進行引數優化，既可以得到最合適的效果。

秦凱新於深圳 20181201

HBase阻塞急救與朱麗葉暫停線上環境解決方案-OLAP商業環境實戰

1 阻塞急救（錦囊妙計）

3 朱麗葉暫停

4 總結

您可能也會喜歡…