[[255986]]

前言

到了年底果然都不太平，最近又收到了運維報警：表示有些服務(wù)器負載非常高，讓我們定位問題。

還真是想什么來什么，前些天還故意把某些服務(wù)器的負載提高(沒錯，老板讓我寫個 BUG!)，不過還好是不同的環(huán)境互相沒有影響。

定位問題

拿到問題后首先去服務(wù)器上看了看，發(fā)現(xiàn)運行的只有我們的 Java 應(yīng)用。于是先用 ps 命令拿到了應(yīng)用的 PID。

接著使用 ps-Hppid 將這個進程的線程顯示出來。輸入大寫的 P 可以將線程按照 CPU 使用比例排序，于是得到以下結(jié)果。

果然某些線程的 CPU 使用率非常高。

為了方便定位問題我立馬使用 jstack pid>pid.log 將線程棧 dump 到日志文件中。

我在上面 100% 的線程中隨機選了一個 pid=194283 轉(zhuǎn)換為 16 進制(2f6eb)后在線程快照中查詢：

因為線程快照中線程 ID 都是16進制存放。

發(fā)現(xiàn)這是 Disruptor 的一個堆棧，前段時間正好解決過一個由于 Disruptor 隊列引起的一次 OOM：強如 Disruptor 也發(fā)生內(nèi)存溢出?

沒想到又來一出。

為了更加直觀的查看線程的狀態(tài)信息，我將快照信息上傳到專門分析的平臺上。

http://fastthread.io/

其中有一項菜單展示了所有消耗 CPU 的線程，我仔細看了下發(fā)現(xiàn)幾乎都是和上面的堆棧一樣。

也就是說都是 Disruptor 隊列的堆棧，同時都在執(zhí)行 java.lang.Thread.yield 函數(shù)。

眾所周知 yield 函數(shù)會讓當前線程讓出 CPU 資源，再讓其他線程來競爭。

根據(jù)剛才的線程快照發(fā)現(xiàn)處于 RUNNABLE 狀態(tài)并且都在執(zhí)行 yield 函數(shù)的線程大概有 30幾個。

因此初步判斷為大量線程執(zhí)行 yield 函數(shù)之后互相競爭導致 CPU 使用率增高，而通過對堆棧發(fā)現(xiàn)是和使用 Disruptor 有關(guān)。

解決問題

而后我查看了代碼，發(fā)現(xiàn)是根據(jù)每一個業(yè)務(wù)場景在內(nèi)部都會使用 2 個 Disruptor 隊列來解耦。

假設(shè)現(xiàn)在有 7 個業(yè)務(wù)類型，那就等于是創(chuàng)建 2*7=14 個 Disruptor 隊列，同時每個隊列有一個消費者，也就是總共有 14 個消費者(生產(chǎn)環(huán)境更多)。

同時發(fā)現(xiàn)配置的消費等待策略為 YieldingWaitStrategy 這種等待策略確實會執(zhí)行 yield 來讓出 CPU。

代碼如下：

初步看來和這個等待策略有很大的關(guān)系。

本地模擬

為了驗證，我在本地創(chuàng)建了 15 個 Disruptor 隊列同時結(jié)合監(jiān)控觀察 CPU 的使用情況。

創(chuàng)建了 15 個 Disruptor 隊列，同時每個隊列都用線程池來往 Disruptor隊列 里面發(fā)送 100W 條數(shù)據(jù)。

消費程序僅僅只是打印一下。

跑了一段時間發(fā)現(xiàn) CPU 使用率確實很高。

同時 dump 線程發(fā)現(xiàn)和生產(chǎn)的現(xiàn)象也是一致的：消費線程都處于 RUNNABLE 狀態(tài)，同時都在執(zhí)行 yield。

通過查詢 Disruptor 官方文檔發(fā)現(xiàn)：

YieldingWaitStrategy 是一種充分壓榨 CPU 的策略，使用 自旋+yield的方式來提高性能。 當消費線程(Event Handler threads)的數(shù)量小于 CPU 核心數(shù)時推薦使用該策略。

同時查閱到其他的等待策略 BlockingWaitStrategy (也是默認的策略)，它使用的是鎖的機制，對 CPU 的使用率不高。

于是在和之前同樣的條件下將等待策略換為 BlockingWaitStrategy。

和剛才的 CPU 對比會發(fā)現(xiàn)到后面使用率的會有明顯的降低;同時 dump 線程后會發(fā)現(xiàn)大部分線程都處于 waiting 狀態(tài)。

優(yōu)化解決

看樣子將等待策略換為 BlockingWaitStrategy 可以減緩 CPU 的使用，

但留意到官方對 YieldingWaitStrategy 的描述里談道： 當消費線程(Event Handler threads)的數(shù)量小于 CPU 核心數(shù)時推薦使用該策略。

而現(xiàn)有的使用場景很明顯消費線程數(shù)已經(jīng)大大的超過了核心 CPU 數(shù)了，因為我的使用方式是一個 Disruptor隊列一個消費者，所以我將隊列調(diào)整為只有 1 個再試試(策略依然是 YieldingWaitStrategy)。

跑了一分鐘，發(fā)現(xiàn) CPU 的使用率一直都比較平穩(wěn)而且不高。

總結(jié)

所以排查到此可以有一個結(jié)論了，想要根本解決這個問題需要將我們現(xiàn)有的業(yè)務(wù)拆分;現(xiàn)在是一個應(yīng)用里同時處理了 N 個業(yè)務(wù)，每個業(yè)務(wù)都會使用好幾個 Disruptor 隊列。

由于是在一臺服務(wù)器上運行，所以 CPU 資源都是共享的，這就會導致 CPU 的使用率居高不下。

所以我們的調(diào)整方式如下：

• 為了快速緩解這個問題，先將等待策略換為 BlockingWaitStrategy，可以有效降低 CPU 的使用率(業(yè)務(wù)上也還能接受)。
• 第二步就需要將應(yīng)用拆分(上文模擬的一個 Disruptor 隊列)，一個應(yīng)用處理一種業(yè)務(wù)類型;然后分別單獨部署，這樣也可以互相隔離互不影響。

當然還有其他的一些優(yōu)化，因為這也是一個老系統(tǒng)了，這次 dump 線程居然發(fā)現(xiàn)創(chuàng)建了 800+ 的線程。

創(chuàng)建線程池的方式也是核心線程數(shù)、***線程數(shù)是一樣的，導致一些空閑的線程也得不到回收;這樣會有很多無意義的資源消耗。

所以也會結(jié)合業(yè)務(wù)將創(chuàng)建線程池的方式調(diào)整一下，將線程數(shù)降下來，盡量的物盡其用。