HBase Memstore專屬JVM策略MSLAB機制深入剖析-OLAP商業環境實戰

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

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

網上的Hbase調優資料參差不齊，實在是不忍卒讀，有些都是拼湊且版本過時的東西，我這裡決定綜合所有優質資源進行整合，寫一份最全，最有深度，不過時的技術部落格。辛苦成文，各自珍惜，謝謝！版權宣告：禁止轉載，歡迎學習，侵權必究！

1 垃圾回收器組合（記憶體碎片）

垃圾回收器從執行緒執行情況分類有三種

• 序列回收，Serial回收器，單執行緒回收，全程stw；
• 並行回收，名稱以Parallel開頭的回收器，多執行緒回收，全程stw；
• 併發回收，cms與G1，多執行緒分階段回收，只有某階段會stw；
• cms只會回收老年代和永久帶（1.8開始為元資料區，需要設定CMSClassUnloadingEnabled），不會收集年輕帶；
• cms是一種預處理垃圾回收器，它不能等到old記憶體用盡時回收，需要在記憶體用盡前，完成回收操作，否則會導致併發回收失敗；所以cms垃圾回收器開始執行回收操作，有一個觸發閾值，預設是老年代或永久帶達到92%；

垃圾回收的四個主要階段：

• 初始標記 初識標記：這個過程是標記從gc root出發發的直接相關的引用。這個時間很短，但是是stop the world;

• 併發標記 併發標記：使用者執行緒並行執行，進行相關的引用標記。這個時間很長，一般決定於堆記憶體的大小。所使用的執行緒數為(cpu個數+3)/4，所以當cpu核數很少時，在併發標記階段會出現嚴重的效能下降。為了解決這個問題，對於cpu核數很少時，在併發標記階段會與使用者執行緒交叉執行，以使伺服器效能不至於下降的太嚴重。但是這樣操作會使標記過程所耗費的時間更長。

• 重新標記 重新標記：因為在併發標記時，使用者執行緒在執行，可能會造成再次的例項引用。所以需要重新標記一下。這個階段的標記也是stop the world,並且是並行標記。

• 併發清除 併發清除，即清除相關的垃圾。

CMS的缺點：

• 由於CMS使用的是標記清除演算法，會造成記憶體碎片，當老年代無法再次分配記憶體時需要FULL GC。CMS提供了一個引數-XX+UseCMSCompactAtFullCollection，即在執行FULL GC時開啟記憶體碎片的合併整理過程。這也會引起stop the world。

• CMS在進行垃圾回收時，無法處理浮動垃圾。所以在進行垃圾回收時，需要留有一定的記憶體供使用者執行緒使用。CMS提供了一個記憶體觸發垃圾回收的記憶體使用比例： -XX:CMSInitiatingOccupancyFraction，如果預留的記憶體不夠使用，就會出現Cocurrent Mode Failure失敗，這時就需要啟動後備預案：臨時使用序列收集器重新進行老年代的垃圾收回，這個時間更長。

• CMS 用來進行老年代的垃圾回收，這個與ParNew（多執行緒的序列垃圾回收）進行組合，用於整個的堆記憶體的垃圾回收。

2 FULL GC 在大記憶體處理的無力感

• 隨著硬體的進步，32GB，64GB甚至100GB的記憶體已經很多了，基於JVM的CMS垃圾回收已經有種無力感，FULL GC的時間遵循8-10秒/G的壓迫。100GB簡直就是災難啊，800-1000秒，可是都接近甚至大於10分鐘了啊。

• 同步模式失敗：CMS在沒有完全釋放老年代的記憶體空間時，新生代物件要過快轉化，導致此時的收集器停止併發收集過程，轉化為單執行緒的暫停，可謂是一觸即發Ful GC。

• 碎片化造成新生代升到老年代的物件比老年代所有可以使用的連續空間都大。比如：老年代有500MB的空間可以使用，但是都是1KB的碎片空間，現在有一個2KB的新生代物件轉換為老年代物件，此時因為沒有2KB的連續空間，所以不得不FullGC。

• MemStore會定期刷寫成為一個HFile，在刷寫的同時這個Memstore所佔用的記憶體空間就會被標記為待回收，但是因為是按照順序的，所以會出現以下情況。

  

• 此時老年代若都是1KB的碎片空間，現在有一個2KB的新生代物件轉換為老年代物件，此時因為沒有2KB的連續空間，所以不得不FullGC。

  

• 因此朱麗葉暫停就誕生了，危機越來越嚴重。

• 基於此，JVM想到了執行緒解決方案，叫做TLAB(Thread-Local allocation Buffer)，當使用TLAB時，每一個執行緒都會分配一個固定大小的記憶體空間，但是缺點就是無論你的執行緒裡面有沒有物件，其中有很大一部分空間都是閒置的，記憶體空間的利用率就會降低。

  

3 HBase的TLAB的昇華MSLAB

• 因為HBase中多個Region是被一個執行緒管理的，但是多個MemStore佔用的記憶體還是無法合理的分開，於是Hbase就自己實現了一套以Memstore為最小單元格的記憶體管理機制，叫做MSLSB（MemStore-Local Allocation Buffers）。這套思路即來自TLAB，只不過記憶體空間是由MemStore來分配。
• MLSB引入chunk的概念，所謂chunk就是一塊記憶體，大小預設為2MB。
• RegionServer中維護者一個全域性的MemStoreChunkPool例項，從名字上很容易看出，是一個Chunk 池。
• 每一個MemStore裡面都會有一個MemStoreLAB例項。
• 當MemStore接收到KeyValue資料的時候先從ChunkPool中申請了一個chunk，然後放到MemStoreLAB例項中。
• 一旦MemStoreLAB例項中放滿了，就新申請一個新的。
• 如果MemStore因為刷寫而釋放記憶體，則按chunk來清空記憶體。
• 上面的流程就解決了小碎片引起的無法插入大資料的問題，

4 MSLAB的引數設定

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的大小。
hbase.hregion.memstore.mslab.chunksize:每一個chunk的大小，預設是2048*1024，即2MB。
hbase.hregion.memstore.mslab.max.allocation:能放入chunk的最大單元格大小，預設是256KB,已經很大了。
複製程式碼

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

5 MSLAB效果

使用前：

使用後：發現完全沒有Full GC

6 MSLAB效果與G1的協同（錦上添花）

因為G1Gc是在 MSLSB之後發明出來的，但是總體上兩者共同使用會有更給力的效能提升： 測試效果：

• RegionServer堆記憶體：64KB.
• JVM回收策略為G1GC
• 採用MSLAB
• 不同批量插入測試
• 50執行緒：G1GC為1262秒，MSLAB為1132.923秒
• 100執行緒：G1GC為2214.201秒，MSLAB為1927.330秒
• 100執行緒：G1GC 次數為475次，MSLAB為403次
• 結論提升了10%到12%

7 總結

本文參考了大量的文件和書籍，辛苦成文不易，尊重原創，謝絕轉載，謝謝！

秦凱新 於深圳 201812011847

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