上週末作了活動期間大量的限流告警提示。因而拜託運維大神先添加機器,暫時頂住壓力。擴容一波增長了一些機器。而後,而後就看到了更多的接口響應超時告警。html
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 ? 線程池耗盡。運維
檢查發現全部請求設置的重試次數都爲0.ide
單次請求超時時間3s.spa
打開 Arthas。.net
thread -b 線程
thread ![]()
發現全部的SimpleAsyncTaskExecutor所有都是阻塞狀態。那麼它們在作什麼呢? ![]()
運維重啓了服務以後SimpleAsyncTaskExecutor 線程逐漸變成阻塞狀態。(剛剛是所有爲阻塞) 3d
thread 378code
thread 146
擴容忽略了數據庫連接。設置白名單問題修復。
按照上面的排查看是與數據庫鏈接出了問題,那這些跟Dubbo的dispatcher策略有沒有關係呢? 網上搜索到了解決方案:(沒有驗證) 修改dubbo provider的dispatcher策略,設置爲message
<dubbo:protocol name=「dubbo」 port=「8888」 threads=「500」 dispatcher=「message」 />
dispatcher默認爲all,全部的請求,均會分發給業務線程池處理。 dubbo默認的業務線程池大小是200,等待隊列長度爲0, 當線程池所有滿了以後,後續的請求會丟棄。 但丟棄的請求也會交給業務線程池處理, 此時可能出現服務端已拒絕,但consumer一直在等待,直到超時