隨著記憶體資源**的降低，伺服器的記憶體越來越大，很多都是達到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:
大資料技術-hbase：mslab介紹
大資料技術
如果沒有乙個好的開始，不妨試試乙個壞的開始吧。因為乙個壞的開始，總比沒有開始強。而完美的開始，則永遠都不會來到。資料採集傳輸主要技術 分為兩類，一類是離線批處理 另一類是實時資料採集和傳輸 離線批處理最有名的是sqoop 實時資料採集和傳輸最為常用的是flume和kafka sqoop 一款開源的離...
大資料技術
前言 學習了好久了，也沒有系統的整理過這些東西，感覺再這麼下去算是荒廢了，懶惰加上不思進取就這樣子過去大半年了，而且最近總是把技術聖地變成自己的宣洩的地方哈哈，隨便寫的啥都亂髮，打擾到各位了，在這裡給各位道歉了 經過乙個比賽感覺自己也學得不紮實，自從非正常退役acm以後，就距離乙個acmer越來越遠...
大資料之大資料技術架構
上期我們說到大資料的概念，其實，大資料比我們想象中的還要複雜，本期，我們主要從技術的角度介紹一下大資料的知識。大資料技術是一系列技術的總稱，它是集合了資料採集與傳輸 資料儲存 資料處理與分析 資料探勘 資料視覺化等技術，是乙個龐大而複雜的技術體系。根據大資料從 到應用，實現傳輸的流程，可以將大資料技...