隨着內存資源價格的降低，服務器的內存越來越大，很多都是達到96GB的。而Hbase的RS又是內存耗用性的，很多時候我們爲其分配了比較大的內存空間。但與此同時，很多人都會遇到配置大內存所導致的各種問題。
首先，我們知道HBase工作依賴於Zookeeper，RS會定期向Master進行狀態彙報，如果長時間沒有收到RS的彙報信息，Master會認爲RS已經死掉，然後開始進行恢復操作。而Zookeeper與RS的會話也可能因爲STW的GC導致會話超時，自己便會退出。
其次，很大堆內存一旦觸發full gc，除了可能導致長時間的停頓，客戶端感覺到明顯的延遲甚至timeout，另外一個比較嚴重的是隨着時間推移，堆內存中存在大量內存碎片，帶來的結果是雖然還有很多空餘內存，但很多是比較小無法分配使用的，promotion failure。
生產環境一般新生代使用ParNew， 老年代用CMS，觸發儘量別配置太大比例，否則容易產生晉升失敗。
HBase提供了以下幾個參數便於利用上一種機制，防止堆中產生過多碎片，大概思路也是參考TLAB，叫做MSLAB，MemStore-Local Allocation Buffer，爲memstore劃分相應的區塊MemStoreLAB，裏面一個字節數組固定的大小（curChunk），用於存放KeyValue的具體數值，還有一個變量用於記錄目前空餘空間偏移指針，當一個Chunk被填滿，重新開闢一個字節數組空間。有效減少了因爲內存碎片導致的full gc。
MSLAB，全稱是 MemStore-Local Allocation Buffer，是Cloudera在HBase 0.90.1時提交的一個patch裏包含的特性。它基於Arena Allocation解決了HBase因Region flush導致的內存碎片問題。
MSLAB的實現原理（對照Arena Allocation，HBase實現細節）：
MemstoreLAB爲Memstore提供Allocator。
創建一個2M（默認）的Chunk數組和一個chunk偏移量，默認值爲0。
當Memstore有新的KeyValue被插入時，通過KeyValue.getBuffer()取得data bytes數組。將data複製到Chunk數組起始位置爲chunk偏移量處，並增加偏移量=偏移量+data.length。
當一個chunk滿了以後，再創建一個chunk。
所有操作lock free，基於CMS原語。
優勢：
KeyValue原始數據在minor gc時被銷燬。
數據存放在2m大小的chunk中，chunk歸屬於memstore。
flush時，只需要釋放多個2m的chunks，chunk未滿也強制釋放，從而爲Heap騰出了多個2M大小的內存區間，減少碎片密集程度。
開啓MSLAB
hbase.hregion.memstore.mslab.enabled=true // 開啓MSALB
hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小，越大內存連續性越好，但內存平均利用率會降低
hbase.hregion.memstore.mslab.max.allocation=256K // 通過MSLAB分配的對象不能超過256K，否則直接在Heap上分配，256K夠大了
from: