HBase 阻塞急救與朱麗葉暫停線上環境解決方案-OLAP商業環境實戰
本套技術專欄是作者(秦凱新)平時工作的總結和昇華,通過從真實商業環境抽取案例進行總結和分享,並給出商業應用的調優建議和叢集環境容量規劃等內容,請持續關注本套部落格。期待加入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 總結
本套技術專欄是作者(秦凱新)平時工作的總結和昇華,通過從真實商業環境抽取案例進行總結和分享,並給出商業應用的調優建議和叢集環境容量規劃等內容,請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址:[email protected],如有任何學術交流,可隨時聯絡。
阻塞問題和朱麗葉暫停問題是兩大範疇的事情,按照優先順序進行引數優化,既可以得到最合適的效果。
秦凱新 於深圳 20181201