hbase內存分配那些事

    最近一直在研究Hbase，上班時間能去研究這些hbase一些稍微深層次的原理，或者作一些有用的優化是很是寶貴的，既能拿錢又能得到寶貴經驗。咳。。有點扯遠了。接下來進入正題。

    一、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掛掉的好不是麼？