hbase守護進程及內存調優

一、HMaster

          HMaster的任務前面已經說過了，兩個大方向：1、管理Hbase Table的 DDL操做 2、region的分配工做，任務不是很艱鉅，可是若是採用默認自動split region的方式，     HMaster會稍微忙一些，負載不大，可適度對此進程作適量放大heap 的操做，但不可太大，由於更耗內存的是HRegionServer

     二、HRegionServer

          這個進程是HBase中的核心守護進程，原則上是每一個slave啓動一個HRegionServer,但多種狀況可能致使HRegionServer 意外退出，下面舉幾個簡單的方面:

•  

•  網絡很差，致使RegionServer 和 HMaster通訊超時，RegionServer被認爲已經掛掉，從而退出集羣 --網絡問題，沒法從軟件方面解決，關於通訊超時的設置下面作個簡單介紹

•  Java full GC ，這個過程會block全部的線程，若是此事件過長，致使Session expired 會話過時，致使退出集羣--下文會闡述

•  各節點時間不一致，致使RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默認是30s，但不要太大，畢竟時間不一致是不正常現象，可將全部節點和同一服務器時間作同步，也能夠和時間服務器同步。

          第一種狀況 和其它緣由致使的RegionServer 超時掛掉的問題，咱們要首先要調高Session的容忍度，默認180000其實這個回話有效期已經夠長的了，可是有的集羣是能夠

   下降了這個值，可能會形成Session 超時，這個參數是 zookeeper.session.timeout 默認18000。

          針對上面這個參數，有的博文認爲即便設爲180000也不能真正的達到目的，由於zookeeper 會將minSessionTimeout 設爲 2*ticktimes ,而將maxSessionTimeout 設爲

   20*ticktimes 當 zookeeper.session.timeout 設置超過20*ticktimes 的時候，系統會取 min(zookeeper.session.timeout,20*ticktimes) 來出來。

          針對上述觀點，我從源碼中找到告終論，首先若是是分佈式的Hbase那 會啓動HQuorumPeer 進程 看下這個源碼：

•  

•           HQuorumPeer.main 方法中會調用 writeMyID(zkProperties) ，而就在此方法中已經將 maxSessionTimeout設置爲 zookeeper.session.timeout 的時長。

•           調用HQuorunPeer.runZKServer

•           調用QuorumPeerMain.runFromConfig

•           設置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());

•           由此可看此件並無直接和tickTime對比的機會。卻是minSessionTimeout沒有設置，默認是2*ticktime

          因而可知 其實若是設置了Zookeeper.session.timeout的話 不會輕易去截取20*ticktime，再不信能夠用echo conf|nc zserver 2181 看一下 zookeeper系統參數

          第二種狀況是要討論的，致使產生這個問題的主要緣由是不少，產生的情景不少，好比在作 major compact的過程當中，時間過長，致使Full GC等，那就儘可能去減小這種情

   況的發生。二個方面

•  

•   適度增大守護進程的HeapSize

•   調整內存回收參數

          第一個方面：Hbase　默認各守護進程爲1G  在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000，當咱們啓動hbase各守護進程的時候，那全部的hbase守護進程都

     將是1000的heapsize，對於有的進程，夠用，但有些進程取遠遠不夠，咱們能夠考慮增大此參數，好比export HBASE-HEAPSIZE=6000 那就把守護進程的heap 內存調大到

     6G,可是這樣會有問題，有些進程不須要這麼多，雖然設置的比較大不影響內存的實際佔用，但卻混淆了對各進程內存佔用的認識。因此上述參數不作改變，在下面的參數中

     修改守護進程Heap 內存。

•  

• export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

•  

• export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC 

                    -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"

•  

• export HBASE_THRIFT_OPTS="$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"

• export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"

            咱們分別對各守護進程設置堆內存 其中-Xmx 表示最大可用內存，-Xms表示出事分配內存 -Xmn 表示 年輕代堆內存分配,這個值網上有的建議按照3/3 總heapsize來設

     置，由於是經驗值，暫沒法考證合理性，更多詳細的堆內存分配參數，本地不作過多闡述，後面有機會可作一個單元來解釋。那其它參數是什麼意思呢?

     -XX：+UseParNewGC 等，這就到了咱們說的第二個方面：

            第二個方面：調整內存回收參數，好比-XX:+UseParNewGC 表示年輕帶內存回收策略採用併發收集，此參數在JDK5.0已經自動配置，不需再手動配置；

     -XX:+UseConcMarkSweepGC 表示年老代併發收集；

     -XX:+CMSInitiatingOccupancyFraction表示年老代內存佔用超過此比例即開始作CMS，這個參數很重要在JDK 5.0之後此值默認是90 也就是當年老代對內存佔用90%以上時，

     纔開始作內存收集，而此時剩餘的10%依然接受從年輕代遷移過來的對象，遷移過快，致使年老代heap 100%時，Full GC 即開始，纔是會暫停全部的任務，直至Full GC 完

     成，此時是形成RegionServer 意外退出的元兇，那爲了安全起見，在調大堆內存的狀況下 蔣此值下降到一個較低的閥值，減小Full GC的產生，那我建議此值設70%。

          三、HQuorumPeer 

               此守護集成是Zookeeper的守護進程，由於咱們用的是Hbase內置的ZooKeeper 因此此進程啓動過程當中，會讀取hbase-env.sh 因此守護進程對內存和 HBASE-HEAPSIZE

     的一致，因此也應在hbase-env.sh中合理設置，見HRegionServer 小節中的參數設置方法。

          四、ThriftServer

               同上