一次RegionServer GC導致會話超時下線的原因分析記錄
查看了regionserver的log日誌：
2017-10-30 03:18:02,718 INFO SecurityLogger.org.apache.hadoop.hbase.Server: Connection from 172.16.4.36 port: 38016 with unknown version info
2017-10-30 03:20:32,334 WARN org.apache.hadoop.hdfs.DFSClient: DFSOutputStream ResponseProcessor exception for block BP-1954737973-172.16.4.81-1498561284109:blk_1237675060_163934648
java.io.EOFException: Premature EOF: no length prefix available
at org.apache.hadoop.hdfs.protocolPB.PBHelper.vintPrefixed(PBHelper.java:2274)
at org.apache.hadoop.hdfs.protocol.datatransfer.PipelineAck.readFields(PipelineAck.java:235)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer$ResponseProcessor.run(DFSOutputStream.java:1076)
2017-10-30 03:20:32,335 INFO org.apache.hadoop.hbase.ScheduledChore: Chore: MovedRegionsCleaner for region my-hbase-srv3,60020,1506017784241 missed its start time
2017-10-30 03:20:32,335 WARN org.apache.hadoop.hdfs.DFSClient: Error Recovery for block BP-1954737973-172.16.4.81-1498561284109:blk_1237675060_163934648 in pipeline
DatanodeInfoWithStorage[172.16.4.94:50010,DS-153f2b54-c56c-461c-8983-e5b79cf7a248,DISK],
DatanodeInfoWithStorage[172.16.4.69:50010,DS-d07aff02-28cf-4467-b089-5d1209614520,DISK],
DatanodeInfoWithStorage[172.16.4.78:50010,DS-8a1665ae-7475-4a76-ae86-b61f5a765e98,DISK]:
bad datanode
DatanodeInfoWithStorage[172.16.4.94:50010,DS-153f2b54-c56c-461c-8983-e5b79cf7a248,DISK]
2017-10-30 03:20:32,335 INFO org.apache.zookeeper.ClientCnxn: Client session timed out, have not heard from server in 168668ms for sessionid 0x25e189c7145bef4, closing socket connection and attempting reconnect
2017-10-30 03:20:32,335 WARN org.apache.hadoop.hbase.util.Sleeper: We slept 150703ms instead of 3000ms, this is likely due to a long garbage collecting pause and it's usually bad 然後就是一系列的由上面的錯誤導致的相關的錯誤。
這裡看到了GC時間太長（153s>60s），導致regionServer的zkSession會話超時，然後認為regionServer下線。
這裡應該是因為當時有個任務寫入資料太多，
大量的資料進入Memstore，佔用記憶體過大，達到了某個臨界值，進行了資料重新整理到hfile的操作，然後GC操作回收記憶體。
下面看看一些memStore的重新整理資料到hfile的條件：
1、MemStore達到上限hbase.hregion.memstore.flush.size 預設是128M的時候，會觸發MemStore的重新整理。這個引數表示單個MemStore的大小的閾值。這個時候是不阻塞寫操作的。
2、當一個Region的MemStore總量達到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size（預設2*128M=256M）時，會阻塞這個region的寫操作，並強制刷寫到HFile。觸發這個重新整理只會發生在MemStore即將寫滿128M時put了一個巨大的記錄的情況，這時會阻塞寫操作，強制重新整理成功才能繼續寫入。
3、一個RegionServer會有很多個Region，很多的MemStore，所以可能單個Region並沒有超過閾值，但是整個RegionServer的記憶體已經佔用非常多了，這時候還有另外兩個引數控制記憶體的刷寫：hbase.regionserver.global.memstore.upperLimit 預設0.4，當RegionServer上全部的MemStore佔用超過heap(heap的大小在hbase-env.sh中設定HBASE_HEAPSIZE，預設1G，我們設定的4G)的40%時，強制阻塞所有的寫操作，將所有的MemStore刷寫到HFile；hbase.regionserver.global.memstore.lowerLimit 預設0.35，表示所有的MemStore佔用超過heap的35%時，會選擇一些佔用記憶體比較大的MemStore阻塞寫操作並進行flush，這是為了降低阻塞全部寫操作flush帶來的問題。
4、當HLog達到最大值（hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize 預設32*64M = 2G）時，也會觸發MemStore的重新整理，強制將更新固化到HFile中，避免在RegionServer crash時恢復時間過長。
5、定期會進行MemStore的重新整理，hbase.regionserver.optionalcacheflushinterval 預設3600000，一小時，確保MemStore的資料不會長時間沒有固化到HFile中。為避免所有的MemStore在同一時間都進行flush導致的問題，定期的flush操作有20000左右的隨機延時。
6、手工可以進行flush操作，在hbase shell呼叫flush，可以針對某個表或者某個region進行flush：
hbase(main):010:0> help 'flush'
Flush all regions in passed table or pass a region row to
flush an individual region. For example:
hbase> flush 'TABLENAME'
hbase> flush 'REGIONNAME'
7、手工flush：
在API中只看到有setMemStoreFlushSize 指定memstore flush到HDFS上的檔案大小，預設是64M，不確定是否可以直接觸發flush MemStore。
結論：
從cm監控看到 該regionserver的圖示資料，由於比較大的資料載入（歸根於region分佈不均導致的）hbase堆記憶體短時間內陡增
從上面判斷應該是超過了 hbase.regionserver.global.memstore.upperLimit(預設0.4) * RegionServer 的heap size。 （不好意思圖片丟了）
，然而GC發生，最後導致zookeeper會話超時。
建議
1 採用預先建立region分割槽，儘量分佈到各個節點上，我這region分佈不均勻是因為叢集遷移之後擴容導致的。後面看看如何將region遷移到其他的節點上。
2 最後應該進行新增叢集的監控，當重啟regionserver下線時候進行報警或者是重啟。
相關推薦
一次RegionServer GC導致會話超時下線的原因分析記錄
查看了regionserver的log日誌： 2017-10-30 03:18:02,718 INFO SecurityLogger.org.apache.hadoop.hbase.Server: Connection from 172.16.4.36 port: 38016 with unknow
記一次生產DB2資料庫鎖超時問題的分析與排查
作者介紹 侯君，證通股份有限公司DBA，主要負責DB2、MySQL、Couchbase運維，以及自動化運維平臺開發，Python愛好者。 前言 DB2的鎖管理機制一直為DB2應用開發人員和DBA所詬病。對其鎖機制不理解的直接後果就是導致鎖超時和死鎖的發生。所以監控並分析鎖超時和死鎖，應是每個DB2
記一次webSphere安裝部署釋出不全原因分析
版本：WebSphere8.5.5.10叢集環境 過程：WebSphere管理平臺更新整個war包是更新完成，啟動報錯，解除安裝重新部署war包也不行，去叢集每個節點發布路徑中檢視釋出的包，發現war
記一次線上gc調優的過程
aspect hash 接下來 JD lac abs rac 數據庫 %x 近期公司運營同學經常表示線上我們一個後臺管理系統運行特別慢，而且經常出現504超時的情況。對於這種情況我們本能的認為可能是代碼有性能問題，可能有死循環或者是數據庫調用次數過多導致接口運
記一次nginx504閘道器超時解決方法
問題發生的背景: 合作方請求某個介面,由於處理時間較長,導致了閘道器超時. 問題分析: 1.可能是php程式超時報錯; 2.php-fpm處理請求超時; 3.nginx伺服器超時. 問題解決: 1.php超時設定: 檢查了php超時的配置,在php.ini
JVM菜鳥進階高手之路六（JVM每隔一小時執行一次Full GC）
JVM菜鳥進階高手之路六（JVM每隔一小時執行一次Full GC） 轉載請註明原創出處，謝謝！ 上次分析詳細地址在：http://www.cnblogs.com/lirenzuo/p/7531700.html 以為上次問題是rmi的問題就此結束了，但是問題並沒有結束，其實本次問
RAC 一次掉盤導致叢集故障
業務反饋，兩臺主機上面的資料庫都宕機了，採用的儲存是資料檔案方式，不是ASM。 上去先檢視叢集狀態。 [[email protected] ~]$ crsctl stat res -t -init --可以看到叢集管理的資源狀態都是offline狀態。 ----
記一次redo損壞導致ora-600[4000]的恢復
據說今天是光棍節，逢年過節，必有大事。快下班的時候，一位朋友碰到了一個大問題，資料庫伺服器異常斷電重啟以後，資料庫無法啟動，報ora-600[4000]錯誤，嘗試了使用隱藏引數，還是無法開啟。 ORA-00704: bootstrap process failure ORA
記一次Redis bitmap導致的miss問題
背景描述 大致需求:指令碼批量匯入使用者資料到redis中，使用bitmap標記使用者是否在匯入的白名單中。使用者量級 億。 過程描述 執行指令碼匯入白名單使用者 5分鐘後發現redi
解Bug之路-記一次中介軟體導致的慢SQL排查過程
解Bug之路-記一次中介軟體導致的慢SQL排查過程 前言 最近發現線上出現一個奇葩的問題，這問題讓筆者定位了好長時間，期間排查問題的過程還是挺有意思的，正好部落格也好久不更新了，就以此為素材寫出了本篇文章。 Bug現場 我們的分庫分表中介軟體在經過一年的沉澱之後，已經到了比較穩定的階段。而且經過線上壓
一次非法關機導致mysql資料表損壞的例項解決
排查修復資料表的經過： 1、訪問網頁，提示錯誤，連線不到資料庫。 2、啟動mysql服務，解除安裝和關閉rpm安裝的mysql服務（昨天安裝postfix好像yum安裝了mysql），用netstat -anp |grep mysqld 命令檢視mysql服務沒有起來，用m
JVM每小時執行一次FULL GC問題
引子 最近分析系統中部分機器記憶體使用率偏高報警問題，發現這部分機器堆記憶體使用率持續增長，當堆記憶體接近上限的時候才會觸發一次FULL GC；其餘機器記憶體使用率整體波動比較穩定，且FULL GC頻率大致是1個小時。 針對這個報警問題，考慮將這部分機器
記一次由於快取導致的bug
bug描述 有一張資料庫表儲存的是 值日員工資訊，有時候可能一次性錄入1個月的資料、有時候也可能隔了很多天沒有錄入資料，也就是說這個錄資料不是很規律。 bug現象:測試人員發現，網站上三亞地區能正常顯示當天值日員工資訊，但是珠海地區卻不能正確顯示當天值日員工資訊。而資料庫上實際是有珠海地區值日員工資訊的。
Linux：記一次異常斷電導致的系統無法正常啟動（檔案系統故障）
因下班時間已到，著急關機！將虛擬機器中的Linux 6.5 x64系統直接關閉電源，重啟後無法正常啟動OS。 1、重啟後現象如下（提示/dev/sda3檔案系統不一致狀態） 2、輸入root密碼後，
解Bug之路-記一次中間件導致的慢SQL排查過程
有一個 bug 第一條 builder mstr 引入 i++ 原來 中間 解Bug之路-記一次中間件導致的慢SQL排查過程 前言 最近發現線上出現一個奇葩的問題，這問題讓筆者定位了好長時間，期間排查問題的過程還是挺有意思的，正好博客也好久不更新了，就以此為素材寫出了本篇文
一次CMS GC問題排查過程（理解原理+讀懂GC日誌）
這個是之前處理過的一個線上問題，處理過程斷斷續續，經歷了兩週多的時間，中間各種嘗試，總結如下。這篇文章分三部分： 1、問題的場景和處理過程；2、GC的一些理論東西；3、看懂GC的日誌 先說一下問題吧 問題場景：線上機器在半夜會推送一個700M左右的資料，這個時候有個資料置換
JVM成長之路,記錄一次記憶體溢位導致頻繁FGC的問題排查及解決
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC 0.00 18.29 97.31 50.26 97.42 95.25
解決springsecurity資源許可權一次載入，導致角色授資源要重啟服務問題
DefaultSecurityMetadataSource Map (放資源選單的許可權對應的) 公用用static型別，拿到了單利類就只有一份，直接就是最早的， //在更新角色選單時更新map roleMenuservice.updateRoleMenu(menuDt
一次線上GC故障解決過程記錄
排查了三四個小時，終於解決了這個GC問題，記錄解決過程於此，希望對大家有所幫助。本文假定讀者已具備基本的GC常識和JVM調優知識，關於JVM調優工具使用可以檢視我在同一分類下的另一篇文章： 背景說明 發生問題的系統部署在Unix上，發生問題前已經跑了兩週多
記一次php curl導致的故障
query rto res 設置 getc ont info transfer lin 情景描述 本地和alpha環境curl請求第三方接口正常beta環境curl請求失敗 代碼如下 public static function getCurl($url, $type