hbase內存分配分析

這篇文章主要講解了“hbase內存分配分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“hbase內存分配分析”吧！

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

    2）GC配置
        不要以為配置了上面的參數就完了，因為你可能會遇到很多情況。比如OOM。為什么？這就要說到java的內存機制了，簡要說說吧，以后會有JVM調優的專題。
        
        上圖是JVM 分代垃圾收集系統的圖表，簡要說一下：

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

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

感謝各位的閱讀，以上就是“hbase內存分配分析”的內容了，經過本文的學習后，相信大家對hbase內存分配分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！