介面無法連線 dubbo 註冊中心，會不斷重試，觸發 dubbo(當前版 本:dubbo-2.5.4-snapshot-jdk1.6-8.4.jar)記憶體洩露 bug，導致 jvm 記憶體逐漸耗光， 最終記憶體溢位。
說明:由於沒有 dubbo 相關的原始碼，無法準確定位 dubbo 記憶體洩露原因，以上結論僅從資料 的相關性分析得出。
2023年9月26日晚上，將介面從provision-inte***ce裡面剝離出來，單獨部署在134.***.***.11，134.***.***.12，134.***.***.13，134.***.***.215，134.***.***.216，134.***.***.217這6臺伺服器上，當晚服務部署完畢，選址功能測試正常。
時間點描述
備註2019.10.09 8:50
運維群收到使用者選址系統無法選址的反饋
2019.10.09 8:55
檢查omc上選址介面服務
2019.10.09 9:00
選址介面服務異常，重啟omc上選址介面服務
2019.10.09 9:05
確認問題恢復，群通知客戶，客戶確認系統使用恢復正常
初步分析了服務執行日誌，10月9日上午7點左右有大量的full gc日誌，其中服務異常時間段內的full gc特別頻繁，1分鐘內有50秒在執行full gc，而且每次full gc能**的記憶體非常少。因為記憶體被消耗完，最終導致服務異常，無法提供正常的選址功能。
現場對介面服務進行了記憶體監控，發現介面服務的記憶體呈現乙個上公升趨勢
10月9日18:00記憶體取樣
10月9日21:00記憶體取樣
10月10日7:00記憶體取樣
結合伺服器執行日誌，初步判斷是記憶體洩漏導致服務異常。
從 9 月 26 日到 10 月 9 日的伺服器日誌檔案(catalina.out.2)分析發現，存在大量(共 98075 次)的 timeoutexception 異常，如下圖
所示:
經分析確認，這部分異常是由於嘗試連線 dubbo 註冊中心失敗導致的，由於無法連線註冊 中心，dubbo 會不斷重試。如下圖所示：
同時，從伺服器日誌檔案(catalina.out.2)中發現，9 月 30 日開始頻繁出現「full gc」資訊:
同時，從伺服器日誌檔案(catalina.out.2)中發現，9 月 30 日開始頻繁出現「full gc」資訊:
10 月 16 日 14:00 從服務 134.***.***.13 節點獲取了實時記憶體 dump 檔案 heap.bin 進行進 一步分析，發現 com.alibaba.dubbo.common.url 建立了 685,963 個例項，占用了約 70%的內 存(1,409,556,408/2,032,436,144=69.35%)
這部分 com.alibaba.dubbo.common.url 物件絕大部分被 3 個執行緒引用: dubboclientreconnecttimer-thread-2 dubboregistryfailedretrytimer-thread-1 dubboclienthandler-134.***.***.149:8001-thread-120 從名稱推斷，這些執行緒和連線失敗重試有關。
從對 134.***.***.13 節點的監控來看 com.alibaba.dubbo.common.url 例項數一直持續增長:
jdk 工具包 jmap jstackeclipsemat或jvisualvm
重點說明：故障發生時可以在重啟服務前通過以下命令儲存現場，以方便事後分析！！！
2.匯出虛擬機器記憶體 dump:jmap -dump:live,format=b,file=heap.bin
3.根據類檢視例項數:jmap -histo
4.儲存伺服器執行日誌
例如：tomcat一般備份./logs/下面日誌檔案 catalina.out 如果日誌有重定向按實際路徑備份
5.保留業務系統報錯截圖或操作步驟
運維分級發布 運維必備制度 故障分級和處罰規範
作者簡介 在接下來的日子裡，將以質量 效率 成本為核心，從運營規劃 管理 流程 規範 系統 平台，監控 告警 安全 優化 考核等幾個維度結合案例來與大家分享自己的體會，內容大致如下所示。正文網際網路產品提供7 24小時服務，而因人為操作 程式bug等原因導致服務不可用是影響服務持續執行的重要原因，為...
日常運維故障記錄和解決
1 esxi 中的虛擬機器無法啟動 報錯 開啟虛擬機器 10.10.3.102 namenode2 的電源時，會收到來自 esx 主機的錯誤。無法啟動虛擬機器。模組 snapshot 開啟電源失敗。無法獲取快照資訊 msg.snapshot.error config。2 salt stack 執行j...
運維（1）什麼是運維
運維，這裡指網際網路運維，通常屬於技術部門，與研發 測試 系統管理同為網際網路產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。乙個網際網路產品的生成一般經歷的過程是 產品經理 需求分析 研發部門開發 測試部門測試 運維部門部署發布以及長期的執行維護。對於初創公司，運維部...