hbase內(nèi)存分配分析

這篇文章主要講解了“hbase內(nèi)存分配分析”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“hbase內(nèi)存分配分析”吧！

    1、hbase-env.sh中的內(nèi)存配置
        hbase-env.sh中可以配置很多東西，比如hbase的heap大小，hbase的gc策略等等。其實(shí)主要就是heap的大小和GC相關(guān)的參數(shù)。
        1）對(duì)于heap，也就是HBASE_HEAPSIZE，默認(rèn)為1G，配置這個(gè)，相當(dāng)于所有的hbase守護(hù)進(jìn)程的heap都使用這個(gè)大小，hbase守護(hù)進(jìn)程有這么幾個(gè)，HMaster、HregionServicer、thrift、Zookeeper相關(guān)進(jìn)程，這里面Zookeeper只的應(yīng)該是hbase自帶的zookeeper，生成環(huán)境一般不會(huì)使用它，在我們的環(huán)境中也不會(huì)使用到thrift，那么對(duì)于HBASE_HEAPSIZE相當(dāng)于給HMaster、HregionServicer配置的堆內(nèi)存大小。
        在網(wǎng)上我看到有篇文章說(shuō)不要直接配置HBASE_HEAPSIZE，因?yàn)槟J(rèn)是所有的守護(hù)進(jìn)程都會(huì)使用HBASE_HEAPSIZE這么大的內(nèi)存，對(duì)于HBASE_ZOOKEEPER，是內(nèi)存的浪費(fèi)。這確實(shí)有道理，但在我們系統(tǒng)中并沒(méi)有啟動(dòng)這些進(jìn)程，所以暫時(shí)可以不考慮每一個(gè)守護(hù)進(jìn)程分配不同的內(nèi)存大小。
        我們目前的系統(tǒng)是使用export HBASE_HEAPSIZE=16384，16G的內(nèi)存，這個(gè)數(shù)字從哪來(lái)呢？相信這還得查看官網(wǎng)，官網(wǎng)不是萬(wàn)能的，但不看官網(wǎng)是萬(wàn)萬(wàn)不能的。一下是官網(wǎng)的一段話： 
   Thus, ~20-24Gb or less memory dedicated to one RS is recommended
        我的英文不是很好，前一句的大概意思是regionserver因?yàn)镚C的原因不能分配太大的內(nèi)存，這句就不用我翻譯了吧。20~24GB或者更小比較適合。嘿嘿。當(dāng)然這個(gè)參數(shù)跟很多因素有關(guān)，以后我會(huì)再深入總結(jié)影響這個(gè)內(nèi)存參數(shù)的因素。姑且先這么多。

    2）GC配置
        不要以為配置了上面的參數(shù)就完了，因?yàn)槟憧赡軙?huì)遇到很多情況。比如OOM。為什么？這就要說(shuō)到j(luò)ava的內(nèi)存機(jī)制了，簡(jiǎn)要說(shuō)說(shuō)吧，以后會(huì)有JVM調(diào)優(yōu)的專(zhuān)題。
        
        上圖是JVM 分代垃圾收集系統(tǒng)的圖表，簡(jiǎn)要說(shuō)一下：

        這里有 3 個(gè)堆分代：Perm（或是 Permanent）代【永久代】，Old Generation 代【老年代】，和 Young 代【年輕代】。年輕代由三個(gè)獨(dú)立的空間組成，Eden 空間和兩個(gè) survivor 空間，S0 和 S1。
        通常，對(duì)象被分配在年輕代的 Eden 空間，如果一個(gè)分配失?。?strong>Eden 滿了），所有 java 線程停止，并且一個(gè)年輕代 GC（Minor GC）被調(diào)用。所有在年輕代存活的對(duì)象（Eden 和 S0 空間）被拷貝到 S1 空間。如果 S1 空間滿了，對(duì)象被拷貝（提升）到老年代。當(dāng)這個(gè)提升失敗，老年代被收集（Major/Full GC）。永久代和老年代通常一起被收集。永久代被用于在存放類(lèi)和對(duì)象中定義的方法。

        回到本話題，我們?cè)O(shè)置GC的參數(shù)為
        export HBASE_OPTS="$HBASE_OPTS -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseParNewGC -XX:ParallelGCThreads=6"
        簡(jiǎn)要說(shuō)明一下，
        -XX:+UseConcMarkSweepGC 表示年老代并發(fā)收集；
        對(duì)于老年代來(lái)說(shuō)， 它可以更早的開(kāi)始回收。當(dāng)分配在老年代的空間比率超過(guò)了一個(gè)閥值，CMS 開(kāi)始運(yùn)行。如果 CMS 開(kāi)始的太晚，HBase 或許會(huì)直接進(jìn)行 full garbage collection。這種情況會(huì)導(dǎo)致block所有的線程，如果這個(gè)時(shí)間過(guò)長(zhǎng)，就會(huì)導(dǎo)致hbase連接超時(shí)，結(jié)果就是regionserver集體下線。這是不能容忍額。為了避免這種情況的發(fā)生，我們建議設(shè)置 -XX:CMSInitiatingOccupancyFraction JVM 參數(shù)來(lái)精確指定在多少百分比 CMS 應(yīng)該被開(kāi)始，正如上面的配置中做的那樣。在 百分之 60 或 70 開(kāi)始是一個(gè)好的實(shí)踐。當(dāng)老年代使用 CMS，默認(rèn)的年輕代 GC 將被設(shè)置成 Parallel New Collector。
        再來(lái)看看hbase為什么可能進(jìn)行full gc，如果我們不配置-XX:CMSInitiatingOccupancyFraction，jdk1.5以后會(huì)使用默認(rèn)值90%，那么很可能，當(dāng)老年代內(nèi)存占用超過(guò)分配給他的內(nèi)存大小的90%，會(huì)進(jìn)行CMS（老年代的回收），但是不會(huì)阻止年輕代到老年代的遷移，如果遷移過(guò)快，CMS較慢，會(huì)出現(xiàn)老年代內(nèi)存使用率100%，這時(shí)會(huì)導(dǎo)致full gc。如果我們把這個(gè)參數(shù)調(diào)整小一點(diǎn)，那么能給年輕帶到老年代遷移的同時(shí)做CMS時(shí)一些時(shí)間，也就減少了full gc的發(fā)生。當(dāng)然這可能會(huì)頻繁的gc，但總比整個(gè)hbase掛掉的好不是么？

感謝各位的閱讀，以上就是“hbase內(nèi)存分配分析”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)hbase內(nèi)存分配分析這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！