HBase記憶體配置及JVM優化

前言

本文從HBase的記憶體布局說起，先充分了解HBase的記憶體區的使用與分配，隨后給出了不同業務場景下的讀寫記憶體分配規劃，并指導如何分析業務的記憶體使用情況，以及在使用當中寫記憶體Memstore及讀記憶體擴展bucketcache的一些注意事項，最后為了保障群集的穩定性減少和降低GC對于集群穩定性的影響，研究及分享了一些關于HBase JVM配置的一些關鍵引數機器作用和范例，希望這些不斷充實的經驗能確保HBase集群的穩定性能更上一個臺階，大家有任何的想法和建議也歡迎一起討論，

HBase的記憶體布局

一臺region server的記憶體使用（如下圖所示）主要分成兩部分:

1.JVM記憶體即我們通常俗稱的堆內記憶體，這塊記憶體區域的大小分配在HBase的環境腳本中設定，在堆內記憶體中主要有三塊記憶體區域，

• 20%分配給hbase regionserver rpc請求佇列及一些其他操作
• 80%分配給memstore + blockcache

2.java direct memory即堆外記憶體，

• 其中一部分記憶體用于HDFS SCR/NIO操作
• 另一部分用于堆外記憶體bucket cache，其記憶體大小的分配同樣在hbase的環境變數腳本中實作

讀寫記憶體規劃

• 寫多讀少型規劃

在詳細說明具體的容量規劃前，首先要明確on heap模式下的記憶體分布圖，如下圖所示：

如圖，整個RegionServer記憶體就是JVM所管理的記憶體，BlockCache用于讀快取；MemStore用于寫流程，快取用戶寫入KeyValue資料；還有部分用于RegionServer正常RPC請求運行所必須的記憶體；

hbase-site.xmll

<property>
<name>hbase.regionserver.global.memstore.size</name>
<value>0.45</value>
</property>
<property>
<name>hfile.block.cache.size</name>
<value>0.3</value>
</property>

• 讀多寫少型規劃

與 on heap模式相比，讀多寫少型需要更多的讀快取，在對讀請求回應時間沒有太嚴苛的情況下，會開啟off heap即啟用堆外記憶體的中的bucket cache作為讀快取的補充，如下圖所示

整個RegionServer記憶體分為兩部分：JVM記憶體和堆外記憶體，其中JVM記憶體中BlockCache和堆外記憶體BucketCache一起構成了讀快取CombinedBlockCache，用于快取讀到的Block資料，其中BlockCache用于快取Index Block和Bloom Block，BucketCache用于快取實際用戶資料Data Block

引數詳解

hbase-site.xml

<property>
<name>hbase.bucketcache.combinedcache.enabled</name>
<value>true</value>
</property>
<property>
<name>hbase.bucketcache.ioengine</name>
<value>offheap</value>  #同時作為master的rs要用heap
</property>
<property>
<name>hbase.bucketcache.size</name>
<value>50176</value>  #單位MB，這個值至少要比bucketcache小1G，作為master的rs用heap，那么這里要填<1的值作為從heap中分配給bucketcache的百分比
</property>
<property>
<name>hbase.regionserver.global.memstore.size</name>
<value>0.60</value>  #heap減小了,那么heap中用于memstore的百分比要增大才能保證用于memstore的記憶體和原來一樣
</property>
<property>
<name>hfile.block.cache.size</nname>
<value>0.20</value>  #使用了bucketcache作為blockcache的一部分,那么heap中用于blockcache的百分比可以減小
</property>

hbase-env.sh

export HBASE_REGIONSERVER_OPTS="-XX:+UseG1GC
-Xms30g –Xmx30g -XX:MaxDirectMemorySize=50g

讀寫記憶體的使用情況

知己知彼方能百戰不殆，在HBase群集的運行程序中，我們需要了解HBase實際情況下的讀寫記憶體使用，才能最大化的對配置做出最加的調整，接下來說下如何查詢HBase運行中讀寫記憶體使用情況
Jmx查詢
http://xxxxxxxx.hadoop.db.com:11111/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Server

memStoreSize代表RegionServer中所有HRegion中的memstore大小的總和，單位是Byte，該值的變化，可以反應出一個RegionServer上寫請求的負載狀況，可以觀察memstoreSize的變化率，如果在單位時間內變化比較抖動，可以近似認為寫操作頻繁，
blockCacheFree代表block cache中空閑的記憶體大小，計算方法為：getMaxSize() – getCurrentSize(),單位是Byte，該值反映出當前BlockCache中還有多少空間可以被利用，
blockCacheSize代表當前使用的blockCache的大小，BlockCache. getCurrentSize()，單位是Byte，該值反映出BlockCache的使用狀況，
以單臺region server配置為例

結合單臺regionserver 的配置來看，讀寫快取都有一定空閑空間，這種情況下可以降低heap size來減少gc的次數和時長，然后我們還需要以群集所有region server的資料來判斷該集群的配置是否合理，如果存在讀寫不均衡和熱點情況都會影響不同region間的快取大小，

Memstore 深度決議

• Memstore簡介

一張資料表由一個或者多個region 組成，在單個region中每個columnfamily組成一個store，在每個store中由一個memstore和多個storefile組成，如下圖所示

HBase是基于LSM-Tree資料結構的，為了提升寫入性能，所有資料寫入操作都會先寫入memstore中（同時會順序寫入WAL），達到指定大小后會對memstore中的資料做次排序后在批量flush磁盤中，此外新寫入的資料有較大概率被讀取到，因此HBase在讀取資料時首先檢查memstore中是否有資料快取，未命中的情況下再去找讀快取，可見memstore無論對于HBase的寫入和讀取性能都至關重要，而其中memstore flush操作又是memstore最核心的操作，

• Memstore Flush操作

• Memstore設定總結

從memstore flush的動作來看，對業務影響最大是regionserver級別的flush操作，假設每個memstore大小為256mb，每個region有兩個cf，整個regionserver上有100個region，根據計算可知，總消耗記憶體 = 256mb2100 = 51.2g >> 0.40*80g = 32g ,很顯然這樣的設定情況下，很容易觸發region server級別的flush操作，對用戶影響較大，
根據如上分析，memstore的設定大小不僅取決于讀寫的比例，也要根據業務的region數量合理分配memstore大小，同樣的我們對每臺regionserver上region的數量及每張表cf的數量上的控制也能達到理想的效果，

堆外記憶體注意事項

Bucketcache的三種作業模式

• heap

heap模式分配記憶體會呼叫byteBuffer.allocate方法，從JVM提供的heap區分配，
記憶體分配時heap模式需要首先從作業系統分配記憶體再拷貝到JVM heap，相比offheap直接從作業系統分配記憶體更耗時，但反之讀取快取時heap模式可以從JVM heap中直接讀取比較快，

• offheap

offheap模式會呼叫byteBuffer.allocateDirect方法，直接從作業系統分配，因為記憶體屬于作業系統，所以基本不會產生CMS GC，也就在任何情況下都不會因為記憶體碎片導致觸發Full GC，
記憶體分配時offheap直接從作業系統分配記憶體比較快，但反之讀取時offheap模式需要首先從作業系統拷貝到JVM heap再讀取，比較費時，

• file

file使用Fussion-IO或者SSD等作為存盤介質，相比昂貴的記憶體，這樣可以提供更大的存盤容量，

堆外記憶體的優勢

使用堆外記憶體，可以將大部分BlockCache讀快取遷入BucketCache，減少jvm heap的size，可以減少GC發生的頻次及每次GC時的耗時
BucketCache沒有使用JVM 記憶體管理演算法來管理快取，而是自己對記憶體進行管理，因此其本身不會因為出現大量碎片導致Full GC的情況發生，

堆外記憶體的缺陷

讀取data block時，需要將off heap的記憶體塊拷貝到jvm heap在讀取，比較費時，對讀性能敏感用戶不太合適，

堆外記憶體使用總結

對于讀多寫少且對讀性能要求不高的業務場景，offheap模式能夠有效的減少gc帶來的影響，線上的vac集群在開啟offheap模式后，GC頻次和耗時都能有效降低，但是因為bucketcache 讀的性能的問題達不到要求而回退到heap模式，

JVM的配置優化及詳解

Hbase服務是基于JVM的，其中對服務可用性最大的挑戰是jvm執行full gc操作,此時會導致jvm暫停服務,這個時候,hbase上面所有的讀寫操作將會被客戶端歸入佇列中排隊,一直等到jvm完成gc操作, 服務在遇到full gc操作時會有如下影響

• hbase服務長時間暫停會導致客戶端操作超時,操作請求處理例外，
• 服務端超時會導致region資訊上報例外丟失心跳，會被zk標記為宕機，導致regionserver即便回應恢復之后，也會因為查詢zk上自己的狀態后自殺,此時hmaster 會將該regionserver上的所有region移動到其他regionserver上

如何避免和預防GC超時的不良影響，我們需要對JVM的引數進行優化
hbase-env.sh

標籤：其他

上一篇：SQL學習筆記系列（二） DQL語言的學習

下一篇：SQL 排序檢索資料