hbase如何實現守護進程及內存調優

這篇文章給大家分享的是有關hbase如何實現守護進程及內存調優的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1、HMaster

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

     2、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%。

          3、HQuorumPeer 

               此守護集成是Zookeeper的守護進程，因為我們用的是Hbase內置的ZooKeeper 所以此進程啟動過程中，會讀取hbase-env.sh 所以守護進程對內存和 HBASE-HEAPSIZE

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

          4、ThriftServer

               同上

感謝各位的閱讀！關于“hbase如何實現守護進程及內存調優”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！