講解 Linux Load 高如何排查的話題屬于老生常談了，但多數(shù)文章只是聚焦了幾個點，缺少整體排查思路的介紹。所謂 “授人以魚不如授人以漁”。本文試圖建立一個方法和套路，來幫助讀者對 Load 高問題排查有一個更全面的認識。

從消除誤解開始

沒有基線的 Load，是不靠譜的 Load

從接觸 Unix/Linux 系統(tǒng)管理的第一天起，很多人就開始接觸 System Load Average 這個監(jiān)控指標了，然而，并非所有人都知道這個指標的真正含義。一般說來，經(jīng)常能聽到以下誤解：

Load 高是 CPU 負載高……
傳統(tǒng) Unix 于 Linux 設計不同。Unix 系統(tǒng)，Load 高就是可運行進程多引發(fā)的，但對 Linux 來說不是。對 Linux 來說 Load 高可能有兩種情況：
系統(tǒng)中處于 R 狀態(tài)的進程數(shù)增加引發(fā)的
系統(tǒng)中處于 D 狀態(tài)的進程數(shù)增加引發(fā)的
Loadavg 數(shù)值大于某個值就一定有問題……
Loadavg 的數(shù)值是相對值，受到 CPU 和 IO 設備多少的影響，甚至會受到某些軟件定義的虛擬資源的影響。Load 高的判斷需要基于某個歷史基線 (Baseline)，不能無原則的跨系統(tǒng)去比較 Load。
Load 高系統(tǒng)一定很忙…..
Load 高系統(tǒng)可以很忙，例如 CPU 負載高，CPU 很忙。但 Load 高，系統(tǒng)不都很忙，如 IO 負載高，磁盤可以很忙，但 CPU 可以比較空閑，如 iowait 高。這里要注意，iowait 本質(zhì)上是一種特殊的 CPU 空閑狀態(tài)。另一種 Load 高，可能 CPU 和磁盤外設都很空閑，可能支持鎖競爭引起的，這時候 CPU 時間里，iowait 不高，但 idle 高。
Brendan Gregg 在最近的博客 [Linux Load Averages: Solving the Mystery] (http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html) 中，討論了 Unix 和 Linux Load Average 的差異，并且回朔到 24 年前 Linux 社區(qū)的討論，并找到了當時為什么 Linux 要修改 Unix Load Average 的定義。文章認為，正是由于 Linux 引入的 D 狀態(tài)線程的計算方式，從而導致 Load 高的原因變得含混起來。因為系統(tǒng)中引發(fā) D 狀態(tài)切換的原因?qū)嵲谑翘嗔耍^非 IO 負載，鎖競爭這么簡單！正是由于這種含混，Load 的數(shù)值更加難以跨系統(tǒng)，跨應用類型去比較。所有 Load 高低的依據(jù)，全都應該基于歷史的基線。本微信公眾號也曾寫過一篇相關文章，可以參見Linux Load Average那些事兒。

如何排查 Load 高的問題

如前所述，由于在 Linux 操作系統(tǒng)里，Load 是一個定義及其含混的指標，排查 loadavg 高就是一個很復雜的過程。其基本思路就是，根據(jù)引起 Load 變化的根源是 R 狀態(tài)任務增多，還是 D 狀態(tài)任務增多，來進入到不同的流程。

這里給出了 Load 增高的排查的一般套路，僅供參考：

在 Linux 系統(tǒng)里，讀取 /proc/stat 文件，即可獲取系統(tǒng)中 R 狀態(tài)的進程數(shù)；但 D 狀態(tài)的任務數(shù)恐怕最直接的方式還是使用 ps 命令比較方便。而 /proc/stat 文件里 procs_blocked 則給出的是處于等待磁盤 IO 的進程數(shù)：

通過簡單區(qū)分 R 狀態(tài)任務增多，還是 D 狀態(tài)任務增多，我們就可以進入到不同的排查流程里。下面，我們就這個大圖的排查思路，做一個簡單的梳理。

R 狀態(tài)任務增多

即通常所說的 CPU 負載高。此類問題的排查定位主要思路是系統(tǒng)，容器，進程的運行時間分析上，找到在 CPU 上的熱點路徑，或者分析 CPU 的運行時間主要是在哪段代碼上。

CPU user 和 sys 時間的分布通常能幫助人們快速定位與用戶態(tài)進程有關，還是與內(nèi)核有關。另外，CPU 的 run queue 長度和調(diào)度等待時間，非主動的上下文切換 (nonvoluntary context switch) 次數(shù)都能幫助大致理解問題的場景。

因此，如果要將問題的場景關聯(lián)到相關的代碼，通常需要使用 perf，systemtap, ftrace 這種動態(tài)的跟蹤工具。

關聯(lián)到代碼路徑后，接下來的代碼時間分析過程中，代碼中的一些無效的運行時間也是分析中首要關注的，例如用戶態(tài)和內(nèi)核態(tài)中的自旋鎖 (Spin Lock)。

當然，如果 CPU 上運行的都是有非常意義，非常有效率的代碼，那唯一要考慮的就是，是不是負載真得太大了。

D 狀態(tài)任務增多

根據(jù) Linux 內(nèi)核的設計， D 狀態(tài)任務本質(zhì)上是 TASK_UNINTERRUPTIBLE 引發(fā)的主動睡眠，因此其可能性非常多。但是由于 Linux 內(nèi)核 CPU 空閑時間上對 IO 棧引發(fā)的睡眠做了特殊的定義，即 iowait，因此iowait 成為 D 狀態(tài)分類里定位是否 Load 高是由 IO 引發(fā)的一個重要參考。

當然，如前所述， /proc/stat 中的 procs_blocked 的變化趨勢也可以是一個非常好的判定因 iowait引發(fā)的 Load 高的一個參考。

CPU iowait 高

很多人通常都對 CPU iowait 有一個誤解，以為 iowait 高是因為這時的 CPU 正在忙于做 IO 操作。其實恰恰相反， iowait 高的時候，CPU 正處于空閑狀態(tài)，沒有任何任務可以運行。只是因為此時存在已經(jīng)發(fā)出的磁盤 IO，因此這時的空閑狀態(tài)被標識成了 iowait ，而不是 idle。

但此時，如果用 perf probe 命令，我們可以清楚得看到，在 iowait 狀態(tài)的 CPU，實際上是運行在 pid 為 0 的 idle 線程上：

相關的 idle 線程的循環(huán)如何分別對 CPU iowait 和 idle 計數(shù)的代碼，如下所示：

而 Linux IO 棧和文件系統(tǒng)的代碼則會調(diào)用 io_schedule，等待磁盤 IO 的完成。這時候，對 CPU 時間被記為 iowait 起關鍵計數(shù)的原子變量 rq->nr_iowait 則會在睡眠前被增加。注意，io_schedule 在被調(diào)用前，通常 caller 會先將任務顯式地設置成 TASK_UNINTERRUPTIBLE 狀態(tài)：

CPU idle 高

如前所述，有相當多的內(nèi)核的阻塞，即 TASK_UNINTERRUPTIBLE 的睡眠，實際上與等待磁盤 IO 無關，如內(nèi)核中的鎖競爭，再如內(nèi)存直接頁回收的睡眠，又如內(nèi)核中一些代碼路徑上的主動阻塞，等待資源。

Brendan Gregg 在最近的博客 [Linux Load Averages: Solving the Mystery] (http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html)中，使用 perf 命令產(chǎn)生的 TASK_UNINTERRUPTIBLE 的睡眠的火焰圖，很好的展示了引起 CPU idle 高的多樣性。本文不在贅述。

因此，CPU idle 高的分析，實質(zhì)上就是分析內(nèi)核的代碼路徑引起阻塞的主因是什么。通常，我們可以使用 perf inject 對 perf record 記錄的上下文切換的事件進行處理，關聯(lián)出進程從 CPU 切出 (swtich out) 和再次切入 (switch in) 的內(nèi)核代碼路徑，生成一個所謂的 Off CPU 火焰圖.

當然，類似于鎖競爭這樣的比較簡單的問題，Off CPU 火焰圖足以一步定位出問題。但是對于更加復雜的因 D 狀態(tài)而阻塞的延遲問題，可能 Off CPU 火焰圖只能給我們一個調(diào)查的起點。

例如，當我們看到，Off CPU 火焰圖的主要睡眠時間是因為 epoll_wait 等待引發(fā)的。那么，我們繼續(xù)要排查的應該是網(wǎng)絡棧的延遲，即本文大圖中的 Net Delay 這部分。

至此，你也許會發(fā)現(xiàn)，CPU iowait 和 idle 高的性能分析的實質(zhì)就是 延遲分析。這就是大圖按照內(nèi)核中資源管理的大方向，將延遲分析細化成了六大延遲分析：

CPU 延遲
內(nèi)存延遲
文件系統(tǒng)延遲
IO 棧延遲
網(wǎng)絡棧延遲
鎖及同步原語競爭
任何上述代碼路徑引發(fā)的 TASK_UNINTERRUPTIBLE 的睡眠，都是我們要分析的對象！

以問題結束

限于篇幅，本文很難將其所涉及的細節(jié)一一展開，因為讀到這里，你也許會發(fā)現(xiàn)，原來 Load 高的分析，實際上就是對系統(tǒng)的全面負載分析。怪不得叫 System Load 呢。這也是 Load 分析為什么很難在一篇文章里去全面覆蓋。