并行運行hbase刪表，建表操作，多個表多個region，導致hbase掛掉。查看日志：

從日志中可以看出GC時間過長導致zookeeper連接超時，master退出。(是master退出而不是regionserver退出是因為進行的操作是建表，刪表，是由master來進行操作的)。

原因：

hbase中和GC相關的參數：

修改前(默認)：

export HBASE_OPTS="$HBASE_OPTS -ea -verbose:gc

-Xloggc:$HBASE_LOG_DIR/hbase.gc.log

-XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCTimeStamps

-XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"

咨詢開發修改后：

export HBASE_OPTS="$HBASE_OPTS -verbose:gc

-Xloggc:$HBASE_LOG_DIR/hbase.gc.log

-XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCDateStamps

-XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=70"

-XXUseConcMarkSweepGC：設置年老代為并發收集。(新老都有)

老：-XX:+CMSIncrementalMode:設置為增量模式。適用于單CPU情況。

新：-XX:+UseParNewGC：設置年輕代為并行收集。可與 CMS 收集同時使用。

-XX:CMSInitiatingOccupancyFraction=70:這個參數是我覺得產生最大作用的。因為最終的目的是減少FULL GC，因為full gc是會block其他線程的。

默認觸發GC的時機是當年老代內存達到90%的時候，這個百分比由 -XX:CMSInitiatingOccupancyFraction=N 這個參數來設置。concurrent mode failed發生在這樣一個場景：

當年老代內存達到90%的時候，CMS開始進行并發垃圾收集，于此同時，新生代還在迅速不斷地晉升對象到年老代。當年老代CMS還未完成并發標記時，年老

代滿了，悲劇就發生了。CMS因為沒內存可用不得不暫停mark，并觸發一次全jvm的stop the

world(掛起所有線程)，然后采用單線程拷貝方式清理所有垃圾對象，也就是full

gc。而我們的bulk的最開始的操作就是各種刪表,建表頻繁的操作，就會使用掉大量master的年輕代的內存，就會發生上面發生的場景，發生full

gc。

解決辦法：CMSInitiatingOccupancyFraction=70表示年老代占到約70%時就開始執行CMS，這樣就不會出現(或很少出現)Full GC了。

總結

以上是生活随笔為你收集整理的hbase 查询设置超时_hbase master挂掉-zookeeper连接超时原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。