Arthas線上實戰：Dubbo線程池耗盡故障排查

線上告警

上週末作了活動期間大量的限流告警提示。因而拜託運維大神先添加機器，暫時頂住壓力。擴容一波增長了一些機器。而後，而後就看到了更多的接口響應超時告警。

2019-06-22 23:32:07,957 WARN [New I/O server worker #1-9] com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport:warn:54 [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-172.***:62075, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 771 (completed: 571), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://172.***:62075!, dubbo version: 2.5.3, current host: 172.16.6.3

Thread pool is EXHAUSTED!

問題排查

what ? 線程池耗盡。

1.客戶端調用重試次數太多？

檢查發現全部請求設置的重試次數都爲0.

2.接口響應超時時間設置的過長？

單次請求超時時間3s.

3.是否是有線程阻塞？

打開 Arthas。

thread -b

thread

發現全部的SimpleAsyncTaskExecutor所有都是阻塞狀態。那麼它們在作什麼呢？

插曲

運維重啓了服務以後SimpleAsyncTaskExecutor 線程逐漸變成阻塞狀態。（剛剛是所有爲阻塞）

繼續查看其中一個

thread 378

owned by DubboServerHandler 繼續往下看

thread 146

整理一下，目前的結論是並不是死鎖，是數據庫查詢這裏出了異常。奇怪，若是數據庫有問題別的同類 服務爲何沒有告警？

請運維大神排查，果真應用於數據庫不在同一個網段，沒有添加到ip白名單。

結論

擴容忽略了數據庫連接。設置白名單問題修復。

思考

按照上面的排查看是與數據庫鏈接出了問題，那這些跟Dubbo的dispatcher策略有沒有關係呢？ 網上搜索到了解決方案:(沒有驗證) 修改dubbo provider的dispatcher策略，設置爲message

<dubbo:protocol name=「dubbo」 port=「8888」 threads=「500」 dispatcher=「message」 />

dispatcher默認爲all，全部的請求，均會分發給業務線程池處理。 dubbo默認的業務線程池大小是200，等待隊列長度爲0， 當線程池所有滿了以後，後續的請求會丟棄。 但丟棄的請求也會交給業務線程池處理， 此時可能出現服務端已拒絕，但consumer一直在等待，直到超時

參考

1.blog.csdn.net/LG772EF/art… 2.www.cnblogs.com/zhukunrong/…