HBase記憶體配置及JVM優化

• 2020 年 12 月 30 日
• 筆記
• HBase

前言

本文從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查詢
//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