hbase針對(duì)full gc所做的優(yōu)化方法是什么

本篇內(nèi)容主要講解“hbase針對(duì)full gc所做的優(yōu)化方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“hbase針對(duì)full gc所做的優(yōu)化方法是什么”吧!

1、最原始的HBase CMS GC相當(dāng)嚴(yán)重，經(jīng)常會(huì)因?yàn)樗槠^多導(dǎo)致Promotion Failure，嚴(yán)重影響業(yè)務(wù)的讀寫請(qǐng)求。
2、分別是針對(duì)Memstore所作的兩個(gè)優(yōu)化：Thread-Local Allocation Buffer和MemStore Chunk Pool
3、以及針對(duì)BlockCache所作的優(yōu)化：BucketCache方案。
4、在詳細(xì)介紹這幾個(gè)優(yōu)化之前有必要簡(jiǎn)單介紹一下HBase GC優(yōu)化的目標(biāo)，很直觀的，
5、第一是要盡量避免長時(shí)間的Full GC，避免影響用戶的讀寫請(qǐng)求；
6、第二是盡量減少GC時(shí)間，提高讀寫性能；
7、接著分別來看HBase針對(duì)GC所做的各種優(yōu)化：

MemStore GC優(yōu)化一 － Thread-Local Allocation Buffer
回顧hbase數(shù)據(jù)寫流程
1、HBase數(shù)據(jù)寫入操作實(shí)際上并沒有直接將數(shù)據(jù)寫入磁盤，
2、而是先寫入內(nèi)存并順序?qū)懭際Log，
3、之后等待滿足某個(gè)特定條件后統(tǒng)一將內(nèi)存中的數(shù)據(jù)刷新到磁盤。
4、一個(gè)RegionServer通常由多個(gè)Region組成，每張Region通常包含一張表的多個(gè)列族，而每個(gè)列族對(duì)應(yīng)一塊內(nèi)存區(qū)域，這塊內(nèi)存被稱為MemStore，
5、很顯然，一個(gè)RegionServer會(huì)由多個(gè)Region構(gòu)成，一個(gè)Region會(huì)由多個(gè)MemStore構(gòu)成。

老版本hbase中：
1、最原始的HBase版本存在很嚴(yán)重的內(nèi)存碎片，經(jīng)常會(huì)導(dǎo)致長時(shí)間的Full GC，其中最核心的問題就出在MemStore這里。
2、因?yàn)橐粋€(gè)RegionServer由多個(gè)Region構(gòu)成，不同Region的數(shù)據(jù)寫入到對(duì)應(yīng)Memstore，
3、在JVM看來其實(shí)是混合在一起寫入Heap（堆內(nèi)存）的

為了優(yōu)化這種內(nèi)存碎片可能導(dǎo)致的Full GC，HBase借鑒了Arena Allocation內(nèi)存管理方式，它通過順序化分配內(nèi)存、內(nèi)存數(shù)據(jù)分塊等特性使得內(nèi)存碎片更加粗粒度，有效改善Full GC情況；

具體實(shí)現(xiàn)原理如下：

1. 每個(gè)MemStore會(huì)實(shí)例化出來一個(gè)MemStoreLAB

2. MemStoreLAB會(huì)申請(qǐng)一個(gè)2M大小的Chunk數(shù)組和一個(gè)Chunk偏移量，初始值為0

3. 當(dāng)一個(gè)KeyValue值插入MemStore后，MemStoreLAB會(huì)首先通過KeyValue.getBuffer()取得data數(shù)組，并將data數(shù)組復(fù)制到Chunk數(shù)組中，之后再將Chunk偏移量往前移動(dòng)data.length

4. 如果當(dāng)前Chunk滿了之后，再調(diào)用new byte[ 2 1024 1024]申請(qǐng)一個(gè)新的Chunk

提示：
很顯然，通過申請(qǐng)2M大小的Chunk可以使得內(nèi)存碎片更加粗粒度，官方在優(yōu)化前后通過設(shè)置 -xx:PrintFLSStatistics = 1
未優(yōu)化前碎片會(huì)大量出現(xiàn)導(dǎo)致頻繁的Full GC，優(yōu)化后雖然依然會(huì)產(chǎn)生大量碎片，但是最大碎片大小一直會(huì)維持在1e＋08左右，極大地降低了Full GC頻率。

MemStore GC優(yōu)化二 – MemStore Chunk Pool
MemStore Chunk Pool的核心思想為：
1、如果這些Chunk能夠被循環(huán)利用，系統(tǒng)就不需要申請(qǐng)新的Chunk，這樣就會(huì)使得YGC頻率降低，晉升到老生代的Chunk就會(huì)減少，CMS GC發(fā)生的頻率就會(huì)降低。

為什么Chunk不能被循環(huán)利用呢？
1、一旦一個(gè)Chunk寫滿之后，系統(tǒng)就會(huì)重新申請(qǐng)一個(gè)新的Chunk，
2、這些Chunk大部分都會(huì)經(jīng)過多次YGC之后晉升到老生代，如果某個(gè)Chunk再?zèng)]有被引用就會(huì)被JVM垃圾回收。
3、很顯然，不斷申請(qǐng)新的Chunk會(huì)導(dǎo)致YGC頻率不斷增多，YGC頻率增加必然會(huì)導(dǎo)致晉升到老生代的Chunk增多，進(jìn)而增加CMS GC發(fā)生的頻率。

具體實(shí)現(xiàn)如下：

1. 系統(tǒng)會(huì)創(chuàng)建一個(gè)Chunk Pool來管理所有未被引用的chunks，這些chunk就不會(huì)再被JVM當(dāng)作垃圾回收掉了

2. 如果一個(gè)Chunk沒有再被引用，將其放入Chunk Pool

3. 如果當(dāng)前Chunk Pool已經(jīng)達(dá)到了容量最大值，就不會(huì)再接納新的Chunk

4. 如果需要申請(qǐng)新的Chunk來存儲(chǔ)KeyValue，首先從Chunk Pool中獲取，如果能夠獲取得到就重復(fù)利用，如果為null就重新申請(qǐng)一個(gè)新的Chunk

官方針對(duì)該優(yōu)化也進(jìn)行了簡(jiǎn)單的測(cè)試，使用jstat -gcutil對(duì)優(yōu)化前后的JVM GC情況進(jìn)行了統(tǒng)計(jì)，具體的測(cè)試條件和測(cè)試結(jié)果如下所示：

測(cè)試條件：
HBase版本：0.94
JVM參數(shù)：-Xms4G -Xmx4G -Xmn2G
單條數(shù)據(jù)大小：Row size=50 bytes, Value size=1024 bytes
實(shí)驗(yàn)方法：50 concurrent theads per client, insert 10,000,000 rows
//cdh中參數(shù)為：
根據(jù) MSLAB 分配方式分配的塊區(qū)大小
hbase.hregion.memstore.mslab.chunksize = 2M
MemStoreChunkPool&MSLAB提升HBASE GC性能 https://blog.csdn.net/map_lixiupeng/article/details/40914567

BlockCache優(yōu)化－BucketCache方案
1、BucketCache。這種方案還是采用“將小碎片整理為大碎片”的思路，
2、由程序在初始化的時(shí)候就申請(qǐng)了很多大小為2M的Bucket，數(shù)據(jù)Block的Get/Cache動(dòng)作只是對(duì)這片空間的訪問/覆寫，CMS碎片會(huì)自然大大降低。

1、其中heap模式表示將數(shù)據(jù)存儲(chǔ)在JVM堆內(nèi)存，
2、offheap模式表示將數(shù)據(jù)Block存儲(chǔ)到操作系統(tǒng)內(nèi)存，
3、file模式表示將數(shù)據(jù)Block存儲(chǔ)到類似于SSD的外部高速緩存上；
//很顯然，offheap模式和file模式根本沒有將數(shù)據(jù)Block存在JVM堆內(nèi)存，所以幾乎不會(huì)出現(xiàn)Full GC，而heap模式即使數(shù)據(jù)存儲(chǔ)在JVM堆內(nèi)存，也會(huì)因?yàn)閮?nèi)存由程序獨(dú)立管理大大降低內(nèi)存碎片。
從結(jié)果可以看出，BucketCache大大減少了碎片的產(chǎn)生，而且YGC和FGC時(shí)間也極大地得到了改善。

到此，相信大家對(duì)“hbase針對(duì)full gc所做的優(yōu)化方法是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！