Arthas | 定位線上 Dubbo 線程池滿異常

  • 2020 年 2 月 26 日
  • 筆記

前言

本文是 Arthas 系列文章的第二篇。

Dubbo 線程池滿異常應該是大多數 Dubbo 用戶都遇到過的一個問題,本文以 Arthas 3.1.7 版本為例,介紹如何針對該異常進行診斷,主要使用到 dashboard/thread 兩個指令。

Dubbo 線程池滿異常介紹

理解線程池滿異常需要首先了解 Dubbo 線程模型,官方文檔:http://dubbo.apache.org/zh-cn/docs/user/demos/thread-model.html。簡單概括下 Dubbo 默認的線程模型:Dubbo 服務端每次接收到一個 Dubbo 請求,便交給一個線程池處理,該線程池默認有 200 個線程,如果 200 個線程都不處於空閑狀態,則

客戶端會報出如下異常:

Caused by: java.util.concurrent.ExecutionException: org.apache.dubbo.remoting.RemotingException: Server side(192.168.1.101,20880) threadpool is exhausted ...  

服務端會打印 WARN 級別的日誌:

[DUBBO] Thread pool is EXHAUSTED!  

引發該異常的原因主要有以下幾點:

  • 客戶端/服務端超時時間設置不合理,導致請求無限等待,耗盡了線程數
  • 客戶端請求量過大,服務端無法及時處理,耗盡了線程數
  • 服務端由於 fullgc 等原因導致處理請求較慢,耗盡了線程數
  • 服務端由於數據庫、Redis、網絡 IO 阻塞問題,耗盡了線程數

原因可能很多,但究其根本,都是因為業務上出了問題,導致 Dubbo 線程池資源耗盡了。所以出現該問題,首先要做的是:

  • 排查業務異常

緊接着針對自己的業務場景對 Dubbo 進行調優:

  • 調整 Provider 端的 dubbo.provider.threads 參數大小,默認 200,可以適當提高。多大算合適?至少 700 不算大;不建議調的太小,容易出現上述問題
  • 調整 Consumer 端的 dubbo.consumer.actives 參數,控制消費者調用的速率。這個實踐中很少使用,僅僅一提
  • 客戶端限流
  • 服務端擴容
  • Dubbo 目前不支持給某個 service 單獨配置一個隔離的線程池,用於保護服務,可能在以後的版本中會增加這個特性

另外,不止 Dubbo 如此設計線程模型,絕大多數服務治理框架、 HTTP 服務器都有業務線程池的概念,所以理論上它們都會有線程池滿異常的可能,解決方案也類似。

那竟然問題都解釋清楚了,我們還需要排查什麼呢?一般在線上,有很多運行中的服務,這些服務都是共享一個 Dubbo 服務端線程池,可能因為某個服務的問題,導致整個應用被拖垮,所以需要排查是不是集中出現在某個服務上,再針對排查這個服務的業務邏輯;需要定位到線程堆棧,揪出導致線程池滿的元兇。

定位該問題,我的習慣一般是使用 Arthas 的 dashboardthread 命令,而在介紹這兩個命令之前,我們先人為的構造一個 Dubbo 線程池滿異常的例子。

復現 Dubbo 線程池滿異常

配置服務端線程池大小

dubbo.protocol.threads=10  

默認大小是 200,不利於重現該異常

模擬服務端阻塞

@Service(version = "1.0.0")  public class DemoServiceImpl implements DemoService {        @Override      public String sayHello(String name) {          sleep();          return "Hello " + name;      }        private void sleep() {          try {              Thread.sleep(5000);          } catch (InterruptedException e) {              e.printStackTrace();          }      }    }  

sleep 方法模擬了一個耗時操作,主要是為了讓服務端線程池耗盡。

客戶端多線程訪問

for (int i = 0; i < 20; i++) {      new Thread(() -> {          while (true){              try {                  Thread.sleep(1000);              } catch (InterruptedException e) {                  e.printStackTrace();              }              try {                  demoService.sayHello("Provider");              } catch (Exception e) {                  e.printStackTrace();              }          }      }).start();  }  

問題復現

客戶端

服務端

問題得以復現,保留該現場,並假設我們並不知曉 sleep 的耗時邏輯,使用 Arthas 來進行排查。

dashboard 命令介紹

$ dashboard  

執行效果

可以看到如上所示的面板,顯示了一些系統的運行信息,這裡主要關注 THREAD 面板,介紹一下各列的含義:

  • ID: Java 級別的線程 ID,注意這個 ID 不能跟 jstack 中的 nativeID 一一對應
  • NAME: 線程名
  • GROUP: 線程組名
  • PRIORITY: 線程優先級, 1~10 之間的數字,越大表示優先級越高
  • STATE: 線程的狀態
  • CPU%: 線程消耗的 CPU 佔比,採樣 100ms,將所有線程在這 100ms 內的 CPU 使用量求和,再算出每個線程的 CPU 使用佔比。
  • TIME: 線程運行總時間,數據格式為分:秒
  • INTERRUPTED: 線程當前的中斷位狀態
  • DAEMON: 是否是 daemon 線程

在空閑狀態下線程應該是處於 WAITING 狀態,而因為 sleep 的緣故,現在所有的線程均處於 TIME_WAITING 狀態,導致後來的請求被處理時,拋出了線程池滿的異常。

在實際排查中,需要抽查一定數量的 Dubbo 線程,記錄他們的線程編號,看看它們到底在處理什麼服務請求。使用如下命令可以根據線程池名篩選出 Dubbo 服務端線程:

dashboard | grep "DubboServerHandler"  

thread 命令介紹

使用 dashboard 篩選出個別線程 id 後,它的使命就完成了,剩下的操作交給 thread 命令來完成。其實,dashboard 中的 thread 模塊,就是整合了 thread 命令,但是 dashboard 還可以觀察內存和 GC 狀態,視角更加全面,所以我個人建議,在排查問題時,先使用 dashboard 縱觀全局信息。

thread 使用示例:

  1. 查看當前最忙的前 n 個線程 $ thread -n 3
  1. 顯示所有線程信息 $ threaddashboard 中顯示一致
  2. 顯示當前阻塞其他線程的線程 $ thread -b No most blocking thread found! Affect(row-cnt:0) cost in 22 ms. 這個命令還有待完善,目前只支持找出 synchronized 關鍵字阻塞住的線程, 如果是 java.util.concurrent.Lock, 目前還不支持
  3. 顯示指定狀態的線程 $ thread --state TIMED_WAITING

線程狀態一共有 [RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, NEW, TERMINATED] 6 種

  1. 查看指定線程的運行堆棧 $ thread 46

介紹了幾種常見的用法,在實際排查中需要針對我們的現場做針對性的分析,也同時考察了我們對線程狀態的了解程度。我這裡列舉了幾種常見的線程狀態:

初始(NEW)

新創建了一個線程對象,但還沒有調用 start() 方法。

運行(RUNNABLE)

Java 線程將就緒(ready)和運行中(running)兩種狀態籠統的稱為「運行」

阻塞(BLOCKED)

線程阻塞於鎖

等待(WAITING)

進入該狀態的線程需要等待其他線程做出一些特定動作(通知或中斷)

  1. Object#wait() 且不加超時參數
  2. Thread#join() 且不加超時參數
  3. LockSupport#park()

超時等待(TIMED_WAITING)

該狀態不同於 WAITING,它可以在指定的時間後自行返回

  1. Thread#sleep()
  2. Object#wait() 且加了超時參數
  3. Thread#join() 且加了超時參數
  4. LockSupport#parkNanos()
  5. LockSupport#parkUntil()

終止(TERMINATED)

標識線程執行完畢

狀態流轉圖

問題分析

分析線程池滿異常並沒有通法,需要靈活變通,我們對下面這些 case 一個個分析:

  • 阻塞類問題。例如數據庫連接不上導致卡死,運行中的線程基本都應該處於 BLOCKED 或者 TIMED_WAITING 狀態,我們可以藉助 thread --state 定位到
  • 繁忙類問題。例如 CPU 密集型運算,運行中的線程基本都處於 RUNNABLE 狀態,可以藉助於 thread -n 來定位出最繁忙的線程
  • GC 類問題。很多外部因素會導致該異常,例如 GC 就是其中一個因素,這裡就不能僅僅藉助於 thread 命令來排查了。
  • 定點爆破。還記得在前面我們通過 grep 篩選出了一批 Dubbo 線程,可以通過 thread ${thread_id} 定向的查看堆棧,如果統計到大量的堆棧都是一個服務時,基本可以斷定是該服務出了問題,至於說是該服務請求量突然激增,還是該服務依賴的某個下游服務突然出了問題,還是該服務訪問的數據庫斷了,那就得根據堆棧去判斷了。

總結

本文以 Dubbo 線程池滿異常作為引子,介紹了線程類問題該如何分析,以及如何通過 Arthas 快速診斷線程問題。有了 Arthas,基本不再需要 jstack 將 16 進制轉來轉去了,大大提升了診斷速度。