建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「捉蟲大師」，作者捉蟲大師。轉(zhuǎn)載本文請聯(lián)系捉蟲大師公眾號。
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站設計、成都網(wǎng)站制作、張家港網(wǎng)絡推廣、微信小程序開發(fā)、張家港網(wǎng)絡營銷、張家港企業(yè)策劃、張家港品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供張家港建站搭建服務，24小時服務熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com
背景
最近某天的深夜，剛洗完澡就接到業(yè)務方打來電話，說他們的 dubbo 服務出故障了，要我協(xié)助排查一下。
電話里，詢問了他們幾點
- 是線上有損故障嗎?——是
- 止損了嗎?——止損了
- 有保留現(xiàn)場嗎?——沒有
于是我打開電腦，連上 網(wǎng)絡看問題。為了便于理解，架構(gòu)簡化如下
只需要關注 A、B、C 三個服務，他們之間調(diào)用都是 dubbo 調(diào)用。
發(fā)生故障時 B 服務有幾臺機器完全夯死，處理不了請求，剩余正常機器請求量激增，耗時增加，如下圖(圖一請求量、圖二耗時)
問題排查
由于現(xiàn)場已被破壞，只能先看監(jiān)控和日志
- 監(jiān)控
除了上述監(jiān)控外，翻看了 B 服務 CPU 和內(nèi)存等基礎監(jiān)控，發(fā)現(xiàn)故障的幾臺機器內(nèi)存上漲比較多，都達到了 80% 的水平線，且 CPU 消耗也變多
這時比較懷疑內(nèi)存問題，于是看了下 JVM 的 fullGC 監(jiān)控
果然 fullGC 時間上漲很多，基本可以斷定是內(nèi)存泄漏導致服務不可用了。但為什么會內(nèi)存泄漏，還無法看出端倪。
- 日志
申請機器權(quán)限，查看日志，發(fā)現(xiàn)了一條很奇怪的 WARN 日志
- [dubbo-future-timeout-thread-1] WARN org.apache.dubbo.common.timer.HashedWheelTimer$HashedWheelTimeout
- (HashedWheelTimer.java:651)
- - [DUBBO] An exception was thrown by TimerTask., dubbo version: 2.7.12, current host: xxx.xxx.xxx.xxx
- java.util.concurrent.RejectedExecutionException:
- Task org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask$$Lambda$674/1067077932@13762d5a
- rejected from java.util.concurrent.ThreadPoolExecutor@7a9f0e84[Terminated, pool size = 0,
- active threads = 0, queued tasks = 0, completed tasks = 21]
可以看出業(yè)務方使用的是2.7.12版本的 dubbo
拿這個日志去 dubbo 的 github 倉庫搜了一下，找到了如下這個 issue：
https://github.com/apache/dubbo/issues/6820
但很快排除了該問題，因為在 2.7.12 版本中已經(jīng)是修復過的代碼了。
繼續(xù)又找到了這兩個 issue：
https://github.com/apache/dubbo/issues/8172
https://github.com/apache/dubbo/pull/8188
從報錯和版本上來看，完全符合，但沒有提及內(nèi)存問題，先不管內(nèi)存問題，看看是否可以按照 #8188 這個 issue 復現(xiàn)
issue 中也說的比較清楚如何復現(xiàn)，于是我搭了這樣三個服務來復現(xiàn)，剛開始還沒有復現(xiàn)。通過修復代碼來反推
刪除代碼部分是有問題，但我們復現(xiàn)卻難以進入這塊，怎么才能進入呢?
這里一個 feature 代表一個請求，只有當請求沒有完成時才會進入，這就好辦了，讓 provider 一直不返回，肯定可以實現(xiàn)，于是在 provider 端測試代碼加入
- Thread.sleep(Integer.MAX_VALUE);
經(jīng)過測試果然復現(xiàn)了，如 issue 所說，當 kill -9 掉第一個 provider 時，消費者全局 ExecutorService 被關閉，當 kill -9 第二個 provider 時，SHARED_EXECUTOR 也被關閉。
那么這個線程池是用來干什么的呢?
它在 HashedWheelTimer 中被用來檢測 consumer 發(fā)出的請求是否超時。
HashedWheelTimer 是 dubbo 實現(xiàn)的一種時間輪檢測請求是否超時的算法，具體這里不再展開，改天可以詳細寫一篇 dubbo 中時間輪算法。
當請求發(fā)出后，如果可以正常返回還好，但如果超過設定的超時時間還未返回，則需要這個線程池的任務來檢測，對已經(jīng)超時的任務進行打斷。
如下代碼為提交任務，當這個線程池被關閉后，提交任務就會拋出異常，超時也就無法檢測。
- public void expire() {
- if (!compareAndSetState(ST_INIT, ST_EXPIRED)) {
- return;
- }
- try {
- task.run(this);
- } catch (Throwable t) {
- if (logger.isWarnEnabled()) {
- logger.warn("An exception was thrown by " + TimerTask.class.getSimpleName() + '.', t);
- }
- }
- }
到這里恍然大悟：如果請求一直發(fā)送，不超時，那是不是有可能撐爆內(nèi)存?于是我又模擬了一下，并且開了 3 個線程一直請求 provider，果然復現(xiàn)出內(nèi)存被撐爆的場景，而當不觸發(fā)這個問題時，內(nèi)存是一直穩(wěn)定在一個低水平上。
這里我用的 arthas 來看的內(nèi)存變化，非常方便
得出結(jié)論
在本地復現(xiàn)后，于是跟業(yè)務方求證一下，這個問題復現(xiàn)還是比較苛刻的，首先得是異步調(diào)用，其次 provider 需要非正常下線，最后 provider 需要有阻塞，即請求一直不返回。
異步調(diào)用得到業(yè)務方的確認，provider 非正常下線，這個比較常見，物理機的故障導致的容器漂移就會出現(xiàn)這個情況，最后 provider 有阻塞這點也得到業(yè)務方的確認，確實 C 服務有一臺機器在那個時間點附近僵死，無法處理請求，但進程又是存活的。
所以這個問題是 dubbo 2.7.12 的 bug 導致。翻看了下這個 bug 是 2.7.10 引入， 2.7.13 修復。
復盤
差不多花了1天的時間來定位和復現(xiàn)，還算順利，運氣也比較好，沒怎么走彎路，但這中間也需要有些地方需要引起重視。
- 止損的同時最好能保留現(xiàn)場，如本次如果在重啟前 dump 下內(nèi)存或摘除流量保留機器現(xiàn)場，可能會幫助加速定位問題。如配置 OOM 時自動 dump 內(nèi)存等其他手段。這也是本起事故中不足的點
- 服務的可觀測性非常重要，不管是日志、監(jiān)控或其他，都要齊全。基本的如日志、出口、進口請求監(jiān)控、機器指標(內(nèi)存、CPU、網(wǎng)絡等)、JVM 監(jiān)控(線程池、GC 等)。這點做的還可以，基本該有的都有
- 開源產(chǎn)品，可從關鍵日志去網(wǎng)絡查找，極大概率你遇到的問題大家也遇到過。這也是這次幸運的點，少走了很多彎路
【責任編輯：武曉燕 TEL：（010）68476606】
當前文章：Dubbo2.7.12bug導致線上故障
轉(zhuǎn)載來于：http://www.5511xx.com/article/cccesii.html
