HBase最佳實(shí)踐－CMS GC調(diào)優(yōu)（從gc本身參數(shù)調(diào)優(yōu)）

同志們，此部分，重要的不能再重要了
1、HBase發(fā)展到當(dāng)下，對(duì)其進(jìn)行的各種優(yōu)化從未停止，而GC優(yōu)化更是其中的重中之重。
hbase gc調(diào)優(yōu)方向
從0.94版本提出MemStoreLAB策略、Memstore Chuck Pool策略對(duì)寫緩存Memstore進(jìn)行優(yōu)化開始，到0.96版本提出BucketCache以及堆外內(nèi)存方案對(duì)讀緩存BlockCache進(jìn)行優(yōu)化，再到后續(xù)2.0版本宣稱會(huì)引入更多堆外內(nèi)存，可見HBase會(huì)將堆外內(nèi)存的使用作為優(yōu)化GC的一個(gè)戰(zhàn)略方向。

然而無(wú)論引入多少堆外內(nèi)存，都無(wú)法避免讀寫全路徑使用JVM內(nèi)存，就拿BucketCache中offheap模式來(lái)講，即使HBase數(shù)據(jù)塊是緩存在堆外內(nèi)存的，但是在讀取的時(shí)候還是會(huì)首先將堆外內(nèi)存中的block加載到JVM內(nèi)存中，再返回給用戶。
這句話的理解在：http://hbasefly.com/2016/04/26/hbase-blockcache-2/
//提到了
BucketCache工作模式 //
比如，內(nèi)存分配時(shí)heap模式需要首先從操作系統(tǒng)分配內(nèi)存再拷貝到JVM heap，相比offheap直接從操作系統(tǒng)分配內(nèi)存更耗時(shí)；但是反過(guò)來(lái)，讀取緩存時(shí)heap模式可以從JVM heap中直接讀取，而offheap模式則需要首先從操作系統(tǒng)拷貝到JVM heap再讀取，顯得后者更費(fèi)時(shí)。

可見，無(wú)論使用多少堆外內(nèi)存，對(duì)JVM內(nèi)存的使用終究是繞不過(guò)去，既然繞不過(guò)去，就還是需要落腳于GC本身，對(duì)GC本身進(jìn)行優(yōu)化。

回顧C(jī)MS GC 算法的工作原理
先上圖：

詳細(xì)請(qǐng)見：https://blog.51cto.com/12445535/2372976

文中對(duì)JVM的內(nèi)存結(jié)構(gòu)以及CMS GC進(jìn)行了相當(dāng)詳細(xì)的介紹。

1. 整個(gè)JVM內(nèi)存由Young區(qū)、Tenured區(qū)和Perm區(qū)三部分組成，其中Young區(qū)又分為一個(gè)Eden區(qū)和兩個(gè)Survivor區(qū)

2. 整個(gè)對(duì)象生命周期簡(jiǎn)要說(shuō)明（一定要爛熟于心，下文會(huì)一直用到）：
   （1）Young區(qū)：一個(gè)對(duì)象初始化之后，首先會(huì)進(jìn)入Eden區(qū)，當(dāng)Eden區(qū)滿之后會(huì)觸發(fā)一次Minor GC，Minor GC會(huì)檢查Eden區(qū)所有對(duì)象是否依舊存活（是否有其他對(duì)象引用），如果存活，會(huì)將其從Eden區(qū)拷貝到Survivor區(qū)，并將這些存活對(duì)象的age加一，而死亡的對(duì)象會(huì)被作為垃圾回收。此時(shí)Eden區(qū)又空閑出來(lái)，等新對(duì)象填充，填充滿之后再會(huì)觸發(fā)Minor GC，如此往復(fù)。需要注意的是，每執(zhí)行一次Minor GC，存活對(duì)象的age就會(huì)加一。
   （2）Tenured區(qū)：一旦存活對(duì)象的age超多一定閾值就會(huì)晉升到Tenured區(qū)，因此可以理解為Tenured區(qū)一般存放長(zhǎng)壽對(duì)象。很顯然，隨著時(shí)間流逝，Tenured區(qū)也會(huì)被填充滿，此時(shí)就會(huì)觸發(fā)CMS GC（old gc），這種GC相對(duì)比較復(fù)雜，由6個(gè)步驟組成分別為（初始標(biāo)記；并發(fā)標(biāo)記；并發(fā)預(yù)清理；重新標(biāo)記；并發(fā)清理；并發(fā)重置。），詳見參考文章。
3. 無(wú)論是Minor GC還是CMS GC，都會(huì)’Stop-The-World’，即停止用戶的一切線程，只留下gc線程回收垃圾對(duì)象。其中Minor GC的STW時(shí)間主要耗費(fèi)在復(fù)制階段（年輕代本身就是copy算法），CMS GC的STW時(shí)間主要耗費(fèi)在標(biāo)示垃圾對(duì)象階段（也就是并發(fā)標(biāo)記和并發(fā)預(yù)清理階段）。

先來(lái)看看GC調(diào)優(yōu)的最終目標(biāo)和基本原則：

1. 平均Minor GC時(shí)間盡可能短。因?yàn)檎麄€(gè)Minor GC都處于STW（STW時(shí)間主要耗費(fèi)在復(fù)制階段），因此短時(shí)間Minor GC會(huì)使用戶讀寫更加平穩(wěn)，延遲可控。
2. CMS GC次數(shù)越少越好。時(shí)間越短越好。一方面是因?yàn)橐淮蜟MS GC一般都會(huì)引起至少秒級(jí)的應(yīng)用暫停，對(duì)用戶讀寫影響較大；另一方面頻繁的CMS GC會(huì)產(chǎn)生大量的內(nèi)存碎片，嚴(yán)重的時(shí)候會(huì)引起Full GC，導(dǎo)致RegionServer宕機(jī)。

下面對(duì)參數(shù)的調(diào)優(yōu)技巧都謹(jǐn)遵以上原則，尤其對(duì)于HBase這類延遲敏感性項(xiàng)目而言，在盡量避免嚴(yán)重影響用戶讀寫的情況下使得GC更加平穩(wěn)、暫停時(shí)間更短！
//也就是遵循一個(gè)原則 不管是minor gc還是cms gc盡量時(shí)間段，減少cms gc的次數(shù)。

CMS GC優(yōu)化技巧（三個(gè)階段 ）

主要分三個(gè)階段進(jìn)行。
1、第一階段會(huì)介紹適用于所有場(chǎng)景下的GC參數(shù)配置，這些參數(shù)不需要太多解釋讀者就可以輕松理解；
2、第二階段和第三階段分別就兩組參數(shù)進(jìn)行調(diào)優(yōu)講解，這兩組參數(shù)一般會(huì)根據(jù)不同的應(yīng)用場(chǎng)景進(jìn)行設(shè)置才能使得GC效果最好，鑒于這兩組參數(shù)的復(fù)雜性，

階段一：默認(rèn)推薦配置 //每個(gè)參數(shù)什么意思講解
-Xmx -Xms -Xmn -Xss -XX:MaxPermSize= M -XX:SurvivorRatio=S -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=N -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=C -XX:-DisableExplicitGC

-Xmx：分配給JVM的最大堆內(nèi)存
-Xms：分配給JVM的初始內(nèi)存，此值一般和Xmx設(shè)置相同
-Xmn：分配給young區(qū)內(nèi)存大小，此值的設(shè)置對(duì)系統(tǒng)性能影響很大，后面第二階段將會(huì)重點(diǎn)討論此值的參數(shù)的調(diào)優(yōu)
-Xss：分配給每個(gè)線程的堆棧大小，在一些對(duì)線程數(shù)敏感的系統(tǒng)中該值設(shè)置比較重要，一般設(shè)置為256K~1M左右
-XX:MaxPermSize= M ：分配給持久代的內(nèi)存大小
-XX:SurvivorRatio=S ： 表示young區(qū)中eden區(qū)和survivor區(qū)的內(nèi)存大小比例，默認(rèn)為8 該值的設(shè)置對(duì)系統(tǒng)性能影響很大，第三階段會(huì)重點(diǎn)討論該參數(shù)的調(diào)優(yōu)
-XX:+UseConcMarkSweepGC ：表示回收器使用CMS CG策略
-XX:+UseParNewGC ：表示young區(qū)采用并行回收機(jī)制 推薦使用 &&&&&
-XX:+CMSParallelRemarkEnabled ： 表示cms的remark階段采用并行的方式，推薦使用 &&&&&
-XX:MaxTenuringThreshold=N ： 表示young區(qū)對(duì)象晉升到Tenured區(qū)的閾值，該值的設(shè)置對(duì)系統(tǒng)的影響很大，在第三節(jié)點(diǎn)會(huì)重點(diǎn)討論*****
-XX:+UseCMSCompactAtFullCollection ：表示每次執(zhí)行完cms gc之后執(zhí)行一次碎片整合 推薦使用 &&&&&
-XX:+UseCMSInitiatingOccupancyOnly ：表示cms gc只基于參數(shù)CMSInitiatingOccupancyFraction觸發(fā)
-Xx:CMSInitiatingOccupancyFraction : 表示當(dāng)tenured（老年代）區(qū)內(nèi)存使用量超過(guò)tenured總大小的百分比超過(guò)該閾值之后會(huì)觸發(fā)cms gc，該值一般設(shè)置為70%~80%
-XX:-DisableExplicitGC ： 表示禁止使用命令System.gc() 該命令用于觸發(fā)整個(gè)JVM的垃圾回收，一般都是長(zhǎng)時(shí)間full gc 推薦使用 &&&&&
-XX:+PrintTenuringDistribution才能打印對(duì)應(yīng)日志，強(qiáng)烈建議線上集群開啟該參數(shù)，&&&&&

使用所有場(chǎng)景下的gc參數(shù)調(diào)優(yōu)
*****通過(guò)上文對(duì)各個(gè)GC參數(shù)的說(shuō)明，可以輕松得出第一階段推薦的參數(shù)設(shè)置如下，這樣的設(shè)置基本適用于所有的場(chǎng)景：
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75% -XX:-DisableExplicitGC

調(diào)優(yōu)預(yù)準(zhǔn)備

1、上文通過(guò)解釋各個(gè)GC參數(shù)意義給出了基本的推薦設(shè)置，同時(shí)也提到幾個(gè)對(duì)性能影響重大的參數(shù)：
2、Xmn、SurvivorRatio以及MaxTenuringThreshold，下面會(huì)通過(guò)理論推理＋實(shí)驗(yàn)驗(yàn)證的方式對(duì)這幾個(gè)參數(shù)在HBase系統(tǒng)的設(shè)置進(jìn)行調(diào)優(yōu)。

需要強(qiáng)調(diào)的是HBase全部配置為BucketCache模式，而不是LruBlockCache。使用了大量堆外內(nèi)存作為讀緩存，在很大程度上優(yōu)化了GC
可見BucketCache模式比LruBlockCache模式GC表現(xiàn)好很多，強(qiáng)烈建議線上配置BucketCache模式。

GC日志分析

介紹完實(shí)驗(yàn)基本條件后，再對(duì)GC日志進(jìn)行簡(jiǎn)單的解釋，方便下文對(duì)日志進(jìn)行分析。需要注意只有在添加參數(shù)-XX:+PrintTenuringDistribution才能打印對(duì)應(yīng)日志，強(qiáng)烈建議線上集群開啟該參數(shù)，

HBase場(chǎng)景內(nèi)存分析
因此可以看出，HBase系統(tǒng)屬于長(zhǎng)壽對(duì)象居多的工程，因此GC的時(shí)候只需要將RPC這類短壽對(duì)象在Young區(qū)淘汰掉就可以達(dá)到最好的GC效果。

階段二：NewParSize調(diào)優(yōu) // 也就是 -Xmn 參數(shù) //細(xì)節(jié)看博客內(nèi)存

NewParSize表示young區(qū)大小，而young區(qū)大小直接決定minor gc的頻率。
minor gc頻率一方面決定單次minor gc的時(shí)間長(zhǎng)短，gc越頻繁，gc時(shí)間就越短；一方面決定對(duì)象晉升到老年代的量，gc越頻繁，晉升到老年代的對(duì)象量就越大。解釋起來(lái)就是：

1. 增大young區(qū)大小，minor gc頻率降低，單次gc時(shí)間會(huì)較長(zhǎng)（young區(qū)設(shè)置更大，一次gc就需要復(fù)制更多對(duì)象，耗時(shí)必然比較長(zhǎng)），業(yè)務(wù)讀寫操作延遲抖動(dòng)較大。反之，業(yè)務(wù)讀寫操作延遲抖動(dòng)較小，比較平穩(wěn)。
2. 減小young區(qū)大小，minor gc頻率增快，但會(huì)加快晉升到老年代的對(duì)象總量（每gc一次，對(duì)象age就會(huì)加一，當(dāng)age超過(guò)閾值就會(huì)晉升到老年代，因此gc頻率越高，age就增加越快），潛在增加old gc風(fēng)險(xiǎn)。

因此設(shè)置NewParSize需要進(jìn)行一定的平衡，不能設(shè)置太大，也不能設(shè)置太小。

小結(jié)：
1、Xmn=2是一個(gè)最優(yōu)的選擇
//Xmn設(shè)置過(guò)小會(huì)導(dǎo)致CMS GC性能較差，而設(shè)置過(guò)大會(huì)導(dǎo)致Minor GC性能較差，
//因此建議在JVM Heap為64g以上的情況下設(shè)置Xmn在1～3g之間
//在32g之下設(shè)置為512m～1g
細(xì)節(jié)：
具體最好經(jīng)過(guò)簡(jiǎn)單的線上調(diào)試；需要特別強(qiáng)調(diào)的是，筆者在很多場(chǎng)合都看到很多HBase線上集群會(huì)把Xmn設(shè)置的很大，比如有些集群Xmx為48g，Xmn為10g，查看日志發(fā)現(xiàn)GC性能極差：?jiǎn)未蜯inor GC基本都在300ms～500ms之間，CMS GC更是很多超過(guò)1s。在此強(qiáng)烈建議，將Xmn調(diào)大對(duì)GC（無(wú)論Minor GC還是CMS GC）沒(méi)有任何好處，不要設(shè)置太大。

階段三：增大Survivor區(qū)大?。p小SurvivorRatio） & 增大MaxTenuringThreshold
1、-XX:SurvivorRatio=S ： 表示young區(qū)中eden區(qū)和survivor區(qū)的內(nèi)存大小比例，默認(rèn)為8 該值的設(shè)置對(duì)系統(tǒng)性能影響很大，第三階段會(huì)重點(diǎn)討論該參數(shù)的調(diào)優(yōu)
2、-XX:MaxTenuringThreshold=N ： 表示young區(qū)對(duì)象晉升到Tenured區(qū)的閾值，該值的設(shè)置對(duì)系統(tǒng)的影響很大，在第三節(jié)點(diǎn)會(huì)重點(diǎn)討論

小結(jié)：
1、一般情況下，默認(rèn)MaxTenuringThreshold=15已經(jīng)相對(duì)比較大，不需要做任何調(diào)整。
2、對(duì)于Minor GC來(lái)說(shuō)，SurvivorRatio設(shè)置對(duì)其影響不是很大。而對(duì)于CMS GC來(lái)說(shuō)，將SurvivorRatio設(shè)置過(guò)大簡(jiǎn)直就是災(zāi)難，性能極其差。而和默認(rèn)值SurvivorRatio=8相比，將SurvivorRatio調(diào)小有利于短壽小對(duì)象更充分地淘汰，因此建議將SurvivorRatio=2

CMS調(diào)優(yōu)結(jié)論

1. 緩存模式采用BucketCache策略O(shè)ffheap模式
2. 對(duì)于大內(nèi)存（大于64G），采用如下配置：
   -Xmx64g -Xms64g -Xmn2g -Xss256k -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
   -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
   -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

總結(jié)：
1、其中Xmn可以隨著Java分配堆內(nèi)存增大而適度增大，但是不能大于4g，取值范圍在1~3g范圍；
2、SurvivorRatio一般建議選擇為2；
3、MaxTenuringThreshold設(shè)置為15；
4、對(duì)于小內(nèi)存（小于64G），只需要將上述配置中Xmn改為512m-1g即可

最后小結(jié)：
通用場(chǎng)景
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75% -XX:-DisableExplicitGC -XX:+PrintTenuringDistribution

cms gc調(diào)優(yōu)（小于64G內(nèi)存的）
-Xmx""g -Xms""g -Xmn1g -Xss256k -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC -XX:+PrintTenuringDistribution

cms gc對(duì)于大內(nèi)存（大于64G），采用如下配置：
-Xmx64g -Xms64g -Xmn2g -Xss256k -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC -XX:+PrintTenuringDistribution

小伙伴的問(wèn)題1： 關(guān)于gc日志的問(wèn)題
博主您好，想請(qǐng)教一下，gc的日志，/var/log/hbase/gc.regionserver.log每次重啟就會(huì)覆蓋，能夠配置成追加寫嗎。有時(shí)hbase報(bào)錯(cuò)，想去查gc的問(wèn)題時(shí)，一旦重啟就沒(méi)了之前的gc日志信息了。
答：
可以看看你的jvm配置 將GC日志設(shè)為3或者更多 -Xloggc:$HBASE_LOG_DIR/gc-regionserver-date +%Y%m%d-%H-%M.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=3

小伙伴的問(wèn)題2：
博主你好，我也是做了好多測(cè)試，發(fā)現(xiàn)不同讀寫比情況下LRU的性能（吞吐、延時(shí)）都要強(qiáng)于CBC，看到文章中也提到了這一點(diǎn)，但還是想不懂為什么CBC要差一些，所以很想請(qǐng)教博主？
答：
因?yàn)镃BC模式下bucketcache（offheap模式）使用堆外內(nèi)存，堆外內(nèi)存讀取會(huì)比jvm內(nèi)存讀取復(fù)雜，流程更多，所以在全內(nèi)存場(chǎng)景喜愛LRU完全好于CBC，在緩存基本不命中場(chǎng)景下兩者吞吐量延遲基本相當(dāng)

全內(nèi)存場(chǎng)景是指？

數(shù)據(jù)量比較小或者有大量熱點(diǎn)讀的場(chǎng)景 大多數(shù)讀都落在BlockCache場(chǎng)景

小伙伴的問(wèn)題3：
范大神，能問(wèn)下你們hbase集群zookeeper.session.timeout這個(gè)參數(shù)設(shè)置多大么，能否通過(guò)調(diào)大這個(gè)參數(shù)來(lái)降低因?yàn)镚C導(dǎo)致的RS連接zk超時(shí)掛掉問(wèn)題呢？ 假如我調(diào)整到比如180秒會(huì)對(duì)hbase造成什么影響嗎？ 萬(wàn)分感謝??！
答：
離線集群的話設(shè)置大點(diǎn)沒(méi)啥問(wèn)題 實(shí)時(shí)在線對(duì)延遲敏感的集群就不能設(shè)置太大

小伙伴的問(wèn)題：
博主方便用 jmap -heap PID 顯示出博主的配置，然后解釋這些參數(shù)嗎？這樣可能更加方便大家看學(xué)習(xí)博主的配置。
我這邊的答案為
[root@hdfs-master-80-121 hbase]# ps -ef|grep hbase
hbase 3004 2490 0 Mar06 ? 00:54:30 /usr/java/jdk1.8.0_102/bin/java -Dproc_regionserver -XX:OnOutOfMemoryError=kill -9 %p -Djava.net.preferIPv4Stack=true -Xms4294967296 -Xmx4294967296 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/hbase_hbase-REGIONSERVER-e72e026ce56e3850d7702a2ca6ecc206_pid3004.hprof -XX:OnOutOfMemoryError=/usr/lib64/cmf/service/common/killparent.sh -Dhbase.log.dir=/var/log/hbase -Dhbase.log.file=hbase-cmf-hbase-REGIONSERVER-hdfs-master-80-121.log.out -Dhbase.home.dir=/opt/cloudera/parcels/CDH-5.9.2-1.cdh6.9.2.p0.3/lib/hbase -Dhbase.id.str= -Dhbase.root.logger=INFO,RFA -Djava.library.path=/opt/cloudera/parcels/CDH-5.9.2-1.cdh6.9.2.p0.3/lib/hadoop/lib/native:/opt/cloudera/parcels/CDH-5.9.2-1.cdh6.9.2.p0.3/lib/hbase/lib/native/Linux-amd64-64 -Dhbase.security.logger=INFO,RFAS org.apache.hadoop.hbase.regionserver.HRegionServer start
hbase 3090 3004 0 Mar06 ? 00:26:57 /bin/bash /usr/lib64/cmf/service/hbase/hbase.sh regionserver start
hbase 6981 3090 0 18:04 ? 00:00:00 sleep 1
root 6983 21889 0 18:04 pts/0 00:00:00 grep --color=auto hbase

[root@hdfs-master-80-121 hbase]# jmap -heap 3004
Attaching to process ID 3004, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.102-b14

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 4294967296 (4096.0MB)
NewSize = 348913664 (332.75MB)
MaxNewSize = 348913664 (332.75MB)
OldSize = 3946053632 (3763.25MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 314048512 (299.5MB)
used = 94743000 (90.35396575927734MB)
free = 219305512 (209.14603424072266MB)
30.168269034817143% used
Eden Space:
capacity = 279183360 (266.25MB)
used = 91102232 (86.8818588256836MB)
free = 188081128 (179.3681411743164MB)
32.63168406598445% used
From Space:
capacity = 34865152 (33.25MB)
used = 3640768 (3.47210693359375MB)
free = 31224384 (29.77789306640625MB)
10.442426867951127% used
To Space:
capacity = 34865152 (33.25MB)
used = 0 (0.0MB)
free = 34865152 (33.25MB)
0.0% used
concurrent mark-sweep generation:
capacity = 3946053632 (3763.25MB)
used = 16010552 (15.268852233886719MB)
free = 3930043080 (3747.9811477661133MB)
0.4057357931013544% used

14606 interned Strings occupying 1393920 bytes.

小伙伴的問(wèn)題6：
您好，請(qǐng)問(wèn)您為什么沒(méi)有使用G1 GC機(jī)制呢？
答：
沒(méi)有用G1GC一方面是因?yàn)槲覀冞@邊內(nèi)存使用量沒(méi)有那么大，另一方面G1GC要用好需要關(guān)注太多參數(shù)配置。不過(guò)以后是一個(gè)大的方向

請(qǐng)問(wèn)有G1調(diào)優(yōu)的嗎 我等了三年了

可以參考下：http://openinx.github.io/ppt/hbaseconasia2017_paper_18.pdf

參考鏈接：
http://hbasefly.com/2016/08/09/hbase-cms-gc/