1. 程式人生 > >HBase 阻塞急救與朱麗葉暫停線上環境解決方案-OLAP商業環境實戰

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