linux性能評估-cpu概念理解篇

• 1.影響Linux服務器性能的因素
  • 1.1 操作系統級
  • 1.2 程序應用級
  • 1.3.系統性能評估標准
• 2.理解“平均負載”
  • 2.1什么是平均負載？（1）uptime
  • 2.2平均負載和CPU使用率
• 3.CPU 上下文切換
  • 3.1 什么是上下文切換
• 4.不可中斷進程和僵屍進程
  • 4.1 查看進行狀態
  • 4.2僵屍進程的影響
• 5.應用的CPU使用率達到100%,應該怎么辦？
  • 5.1怎么查看 CPU 使用率
  • 5.2 CPU 使用率過高怎么辦？
• 5.怎么理解Linux軟中斷
  • 1.從“取外賣”看中斷
  • 2.軟中斷
  • 3.查看軟中斷和內核線程
• 6.套路總結篇
  • 6.1cpu使用率高，但是卻找不到CPU高的應用：
  • 6.2cpu使用率100%，該怎么辦？
  • 6.3系統中出現大量不可中斷進程和僵屍進程怎么辦？
  • 6.4.軟中斷 CPU 使用率過高，該怎么辦？
  • 6.5 當平均負載高於CPU數量70%的時候，應該分析負載高的問題；
  • 6.6 大量CPU上下文切換；
  • 6.7 CPU 性能分析的思路圖譜

1.影響Linux服務器性能的因素

1.1 操作系統級

性能調優是找出系統瓶頸並消除這些瓶頸的過程。 很多系統管理員認為性能調優僅僅是調整一下內核的參數即可解決問題， 事實上情況並不是這樣。 性能調優是實現操作系統的各個子系統之間的平衡性，這些子系統包括：

•        CPU
•        內存
•        磁盤I/O帶寬
•        網絡I/O帶寬

子系統之間相互依存，任何一個子系統的負載過度都能導致其他子系統出現問題，例如：

• 大量的 page-in IO 請求可能導致內存隊列被塞滿
• 網卡的巨量吞吐可能導致 CPU 資源耗盡
• 系統嘗試保持釋放內存隊列時可能耗盡 CPU 資源
• 來自內存的大量磁盤寫入請求可能導致 CPU 資源和 IO 通道耗盡

性能調優的前提是找出系統瓶頸之所在， 盡管問題看似由某個子系統所導致， 然而這很可能是另外一個子系統的過載所引起的。

1.2 程序應用級

為了明白從何處開始着手調整性能瓶頸， 弄清被分析系統的性能表現是首要任務。 任何系統的應用常可分為以下兩類：

• IO 限制型——一個 IO 限制型的應用需要大量的內存和基礎存儲設備占用。 因其需要大量的數據讀寫請求，此類應用對 CPU 和網絡需求不高（除非存儲系統在網絡上） 。
•  IO 限制型應用使用 CPU 資源來進行 IO 操作且常進入睡眠狀態。 數據庫應用常被認為屬於此類。
• CPU 限制型——一個 CPU 限制型應用需要大量的 CPU 資源，來進行批量的處理或大量的計算。大容量 web 服務，mail 服務，以及任何類型的渲染服務都被歸到此類。

1.3.系統性能評估標准

我們在進行壓測時，可以用來判斷系統好壞的一個標准，可以參考如下表格的一個標准：

影響性能因素	評判標准
	好	壞	糟糕
CPU	user% + sys%< 70%	user% + sys%= 85%	user% + sys% >=90%
內存	Swap In（si）＝0 Swap Out（so）＝0	Per CPU with 10 page/s	More Swap In & Swap Out
磁盤	iowait % < 20%	iowait % =35%	iowait % >= 50%

其中：
       %user：表示CPU處在用戶模式下的時間百分比。
       %sys：表示CPU處在系統模式下的時間百分比。
       %iowait：表示CPU等待輸入輸出完成時間的百分比。
       swap in：即si，表示虛擬內存的頁導入，即從SWAP DISK交換到RAM。
       swap out：即so，表示虛擬內存的頁導出，即從RAM交換到SWAP DISK。

2.理解“平均負載”

2.1什么是平均負載？
（1）uptime

• 15:04:40 #系統當前時間
• up 31 days, 21:45#系統運行時間
• 1 user#正在登錄用戶數
• load average: 0.01, 0.01, 0.00
• 最后三個數字，依次則是過去 1 分鍾、5 分鍾、15 分鍾的平均負載（Load Average）

平均負載：是指單位時間內，系統處於可運行狀態和不可中中斷狀態的平均進程數，也就是平均活躍進程數，它和 CPU 使用率沒有直接關系。
這里需要注意的是：load average這個輸出值，這三個值的大小一般不能大於系統CPU的個數。例如，本輸出中系統有16個CPU,如果load average的三個值長期大於16時，說明CPU很繁忙，負載很高，可能會影響系統性能，但是偶爾大於16時，倒不用擔心，一般不會影響系統性能。相反，如果load average的輸出值小於CPU的個數，則表示CPU還有空閑的時間片，比如本例中的輸出，CPU是非常空閑的。
也可以通過查詢文件/proc/loadavg獲取系統在前一分鍾、前五分鍾和前十五分鍾的平均負載以及當前運行的進程、系統的進程數和上一次調度運行的進程。

（2）top

• 前五行是系統整體的統計信息。
• 第一行是任務隊列信息，同 uptime 命令的執行結果。其內容如下：當前時間；系統運行時間，格式為時:分；當前登錄用戶數；系統負載，即任務隊列的平均長度。
• 第二、三行為進程和CPU的信息。當有多個CPU時，這些內容可能會超過兩行。
• 內容如下：Tasks: 175 total 進程總數；1 running正在運行的進程數；338 sleeping睡眠的進程數；0 stopped停止的進程數；0 zombie僵屍進程數
• Cpu(s):1.4% us用戶空間占用CPU百分比
• 1.4%sy內核空間占用CPU百分比
• 0.0%ni用戶進程空間內改變過優先級的進程占用CPU百分比
• 97.2%id空閑CPU百分比
• 0.0%wa等待輸入輸出的CPU時間百分比
• 0.0%si swap in，表示虛擬內存的頁導入，即從SWAPDISK交換到RAM。
• 0.0%st swap out，表示虛擬內存的頁導出，即從RAM交換到SWAPDISK。
• PR：操作系統給進程的安排的優先級。這個值表示進程調度器分配給進程的時間片長度。單位是時鍾個數。如果一個Linux系統的時間片是10ms，那么PID是2718的進程在執行了200ms后，才會進行進程切換。 
• RES：進程占用的物理內存大小。          
• VIRT：物理內存+虛擬內存。  

2.2平均負載和CPU使用率

平均負載是指單位時間內，處於可運行狀態和不可中斷狀態的進程數。它不僅包括了正在使用CPU的進程，還包括等待CPU和等待I/O的進程。
CPU使用率，是單位時間內CPU繁忙情況的統計，跟平均負載並不一定完全對應。
CPU 密集型進程，使用大量 CPU 會導致平均負載升高，此時這兩者時一致的。
I/O 密集型進程，等待 I/O 也會導致平均負載升高，但CPU使用率不一定很高。
大量等待 CPU 的進程調度也會導致平均負載升高，此時的CPU使用率也會比價高。

3.CPU 上下文切換

3.1 什么是上下文切換

上下文切換：CPU切換到另一個進程需要保存當前進程的狀態並恢復另一個進程的狀態：當前運行任務轉為就緒（或者掛起、中斷）狀態，另一個被選定的就緒任務成為當前任務。進程調度包括保存當前任務的運行環境，恢復將要運行任務的運行環境。
1.vmstat使用
vmstat是一個常用的系統性能分析工具，主要用來分析系統的內存使用情況，也常來分析CPU上下文切換和中斷的次數。
#每隔 5 秒輸出 1 組數據

• cs :每秒上下文切換的次數；
• in：每秒中斷的次數；
• r:就緒隊列的長度，也就是正在運行的等待CPU的進程數；
• b:處於不可中斷睡眠狀態的進程數；

以上vmstat只給出了系統總體的上下文切換的情況，使用pidstat,並加上-w，可以查看每個進程上下文切換的情況；
例如：

這里有我們需要重點關注的對象，就是cswch(每秒自願上下文切換)的次數，nvcswch(每秒非自願上下文切換)的次數。它們意味着不同的性能問題：
所謂自願上下文切換，是指進程無法獲取所需資源，導致的上下文切換。比如說，I/O，內存等系統資源不足時，就會發生自願上下文切換。
而非而非自願上下文切換，則是指進程由於時間片已到等原因，被系統強制調度，進而發生的上下文切換。比如說，大量進程都在爭搶CPU時，就容易發生非自願上下文切換。

4.不可中斷進程和僵屍進程

4.1 查看進行狀態

使用top命令查看：

• R 是 Running 或 Runnable 的縮寫，表示進程在 CPU 的就緒隊列中，正在運行或者正在等待運行。
• D 是 Disk Sleep 的縮寫，也就是不可中斷狀態睡眠（Uninterruptible Sleep），一般表示進程正在跟硬件交互，並且交互過程不允許被其他進程或中斷打斷。
• S 是 Interruptible Sleep 的縮寫，也就是可中斷狀態睡眠，表示進程因為等待某個事件而被系統掛起。當進程等待的事件發生時，它會被喚醒並進入 R 狀態。
• Z 是 Zombie 的縮寫，它表示僵屍進程，也就是進程實際上已經結束了，但是父進程還沒有回收它的資源（比如進程的描述符、PID 等）。
• I 是 Idle 的縮寫，也就是空閑狀態，用在不可中斷睡眠的內核線程上。前面說了，硬件交互導致的不可中斷進程用 D 表示，但對某些內核線程來說，它們有可能實際上並沒有任何負載，用Idle 正是為了區分這種情況。要注意，D 狀態的進程會導致平均負載升高， I 狀態的進程卻不會。

4.2僵屍進程的影響

一旦父進程沒有處理子進程的終止，還一直保持運行狀態，那么子進程就會一直處於僵屍狀態。大量的僵屍進程會用盡 PID 進程號，導致新進程不能創建，所以這種情況一定要避免。

5.應用的CPU使用率達到100%,應該怎么辦？

5.1怎么查看 CPU 使用率

使用命令top

• user（通常縮寫為 us），代表用戶態 CPU 使用率.
• nice（通常縮寫為 ni），代表低優先級用戶態 CPU 使用率，也就是進程的 nice 值被調整為 1-19 之間時的 cpu使用率。
• system（通常縮寫為 sys），代表內核態 CPU 使用率。
• idle（通常縮寫為 id），代表空閑CPU。
• iowait（通常縮寫為 wa），代表等待 I/O 的 CPU使用率。
• irq（通常縮寫為 hi），代表處理硬中斷的 CPU 使用率。
• softirq（通常縮寫為 si），代表處理軟中斷的 CPU使用率。
• steal（通常縮寫為 st），代表當系統運行在虛擬機中的時候，被其他虛擬機占用的 CPU 使用率。

5.2 CPU 使用率過高怎么辦？

（1）第一種常見用法是 perf top
類似於 top，它能夠實時顯示占用 CPU 時鍾最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示:

• 第一列 Overhead ，是該符號的性能事件在所有采樣中的比例，用百分比來表示。
• 第二列 Shared ，是該函數或指令所在的動態共享對象（Dynamic Shared Object），如內核、進程名、動態鏈接庫名、內核模塊名等。
• 第三列 Object ，是動態共享對象的類型。比如 [.]表示用戶空間的可執行程序、或者動態鏈接庫，而 [k] 則表示內核空間。
• 最后一列 Symbol 是符號名，也就是函數名。當函數名未知時，用十六進制的地址來表示。

(2)第二種常見用法，也就是 perf record 和 perf report

perf record 則提供了保存數據的功能，保存后的數據需要你用 perf report 解析展示.
如下：

$ perf record -p -g 進程pid # 按 Ctrl+C 終止采樣,加上g參數可以顯示函數的調用關系

$ perf report # 展示類似於 perf top 的報告,報告展示如下：

總結：

• CPU 使用率是最直觀和最常用的系統性能指標，更是我們在排查性能問題時，通常會關注的第一個指標。所以我們更要熟悉它的含義，尤其要弄清楚用戶（%user）、Nice（%nice）、系統（%system） 、等待 I/O（%iowait） 、中斷（%irq）以及軟中斷（%softirq）這幾種不同 CPU 的使用率。比如說：
• a.用戶 CPU 和 Nice CPU 高，說明用戶態進程占用了較多的 CPU，所以應該着重排查進程的性能問題。
• b.系統 CPU 高，說明內核態占用了較多的 CPU，所以應該着重排查內核線程或者系統調用的性能問題。
• c.I/O 等待 CPU 高，說明等待 I/O 的時間比較長，所以應該着重排查系統存儲是不是出現了 I/O 問題。
• d.軟中斷和硬中斷高，說明軟中斷或硬中斷的處理程序占用了較多的CPU，所以應該着重排查內核中的中斷服務程序。
  
  

5.怎么理解Linux軟中斷

1.從“取外賣”看中斷

中斷是系統用來響應硬件設備請求的一種機制，它會打斷進程的正常調度和執行，然后調用內核中的中斷處理程序來響應設備的請求。

中斷的作用:

比如說你訂了一份外賣，但是不確定外賣什么時候送到，也沒有別的方法了解外賣的進度，但是，配送員送外賣是不等人的，到了你這兒沒人取的話，就直接走人了。所以你只能苦苦等着，時不時去門口看看外賣送到沒，而不能干其他事情。

不過呢，如果在訂外賣的時候，你就跟配送員約定好，讓他送到后給你打個電話，那你就不用苦苦等待了，就可以去忙別的事情，直到電話一響，接電話、取外賣就可以了。

這里的“打電話”，其實就是一個中斷。沒接到電話的時候，你可以做其他的事情；只有接到了電話（也就是發生中斷），你才要進行另一個動作：取外賣。

這個例子你就可以發現，中斷其實是一種異步的事件處理機制，可以提高系統的並發處理能力.

由於中斷處理程序會打斷其他進程的運行，所以，為了減少對正常進程運行調度的影響，中斷處理程序就需要盡可能快地運行。如果中斷本身要做的事情不多，那么處理起來也不會有太大問題；但如果中斷要處理的事情很多，中斷服務程序就有可能要運行很長時間。

特別是，中斷處理程序在響應中斷時，還會臨時關閉中斷。這就會導致上一次中斷處理完成之前，其他中斷都不能響應，也就是說中斷有可能會丟失。

那么還是以取外賣為例。假如你訂了 2 份外賣，一份主食和一份飲料，並且是由 2 個不同的配送員來配送。這次你不用時時等待着，兩份外賣都約定了電話取外賣的方式。但是，問題又來了。

當第一份外賣送到時，配送員給你打了個長長的電話，商量發票的處理方式。與此同時，第二個配送員也到了，也想給你打電話。

但是很明顯，因為電話占線（也就是關閉了中斷響應），第二個配送員的電話是打不通的。所以，第二個配送員很可能試幾次后就走掉了（也就是丟失了一次中斷）。

2.軟中斷

如果你弄清楚了“取外賣”的模式，那對系統的中斷機制就很容易理解了。事實上，為了解決中斷處理程序執行過長和中斷丟失的問題，Linux 將中斷處理過程分成了兩個階段，也就是上半部和下半部:

• 上半部用來快速處理中斷，它在中斷禁止模式下運行，主要處理跟硬件緊密相關的或時間敏感的工作。
• 下半部用來延遲處理上半部未完成的工作，通常以內核線程的方式運行
  
  比如說前面取外賣的例子，上半部就是你接聽電話，告訴配送員你已經知道了，其他事兒見面再說，然后電話就可以掛斷了；下半部才是取外賣的動作，以及見面后商量發票處理的動作。

這樣，第一個配送員不會占用你太多時間，當第二個配送員過來時，照樣能正常打通你的電話。

除了取外賣，我再舉個最常見的網卡接收數據包的例子，讓你更好地理解。

網卡接收到數據包后，會通過硬件中斷的方式，通知內核有新的數據到了。這時，內核就應該調用中斷處理程序來響應它。你可以自己先想一下，這種情況下的上半部和下半部分別負責什么工作呢？

對上半部來說，既然是快速處理，其實就是要把網卡的數據讀到內存中，然后更新一下硬件寄存器的狀態（表示數據已經讀好了），最后再發送一個軟中斷信號，通知下半部做進一步的處理。

而下半部被軟中斷信號喚醒后，需要從內存中找到網絡數據，再按照網絡協議棧，對數據進行逐層解析和處理，直到把它送給應用程序。

所以，這兩個階段你也可以這樣理解：

• 上半部直接處理硬件請求，也就是我們常說的硬中斷，特點是快速執行；
• 而下半部則是由內核觸發，也就是我們常說的軟中斷，特點是延遲執行。
  

實際上，上半部會打斷 CPU 正在執行的任務，然后立即執行中斷處理程序。而下半部以內核線程的方式執行，並且每個 CPU 都對應一個軟中斷內核線程，名字為 “ksoftirqd/CPU 編號”，比如說， 0 號 CPU 對應的軟中斷內核線程的名字就是 ksoftirqd/0。

不過要注意的是，軟中斷不只包括了剛剛所講的硬件設備中斷處理程序的下半部，一些內核自定義的事件也屬於軟中斷，比如內核調度和 RCU 鎖（Read-Copy Update 的縮寫，RCU 是 Linux 內核中最常用的鎖之一）等。

3.查看軟中斷和內核線程

前面提到過的 proc 文件系統。它是一種內核空間和用戶空間進行通信的機制，可以用來查看內核的數據結構，或者用來動態修改內核的配置。其中：

• /proc/softirqs 提供了軟中斷的運行情況；
• /proc/interrupts 提供了硬中斷的運行情況。
  

運行下面的命令，查看 /proc/softirqs 文件的內容，你就可以看到各種類型軟中斷在不同 CPU 上的累積運行次數：

$ cat /proc/softirqs

                     CPU0       CPU1

           HI:          0          0

        TIMER:     811613    1972736

       NET_TX:         49          7

       NET_RX:    1136736    1506885

        BLOCK:          0          0

     IRQ_POLL:          0          0

      TASKLET:     304787       3691

        SCHED:     689718    1897539

      HRTIMER:          0          0

          RCU:    1330771    1354737

在查看 /proc/softirqs 文件內容時，你要特別注意以下這兩點。

第一，要注意軟中斷的類型，也就是這個界面中第一列的內容。從第一列你可以看到，軟中斷包括了 10 個類別，分別對應不同的工作類型。比如 NET_RX 表示網絡接收中斷，而 NET_TX 表示網絡發送中斷。

第二，要注意同一種軟中斷在不同 CPU 上的分布情況，也就是同一行的內容。正常情況下，同一種中斷在不同 CPU 上的累積次數應該差不多。比如這個界面中，NET_RX 在 CPU0 和 CPU1 上的中斷次數基本是同一個數量級，相差不大。

不過你可能發現，TASKLET 在不同 CPU 上的分布並不均勻。TASKLET 是最常用的軟中斷實現機制，每個 TASKLET 只運行一次就會結束 ，並且只在調用它的函數所在的 CPU 上運行。

因此，使用 TASKLET 特別簡便，當然也會存在一些問題，比如說由於只在一個 CPU 上運行導致的調度不均衡，再比如因為不能在多個 CPU 上並行運行帶來了性能限制。

另外，軟中斷實際上是以內核線程的方式運行的，每個 CPU 都對應一個軟中斷內核線程，這個軟中斷內核線程就叫做 ksoftirqd/CPU 編號。那要怎么查看這些線程的運行狀況呢？

其實用 ps 命令就可以做到，比如執行下面的指令：

$ ps aux | grep softirq

root         7  0.0  0.0      0     0 ?        S    Oct10   0 : 01 [ksoftirqd/ 0 ]

root        16  0.0  0.0      0     0 ?        S    Oct10   0 : 01 [ksoftirqd/ 1 ]

注意，這些線程的名字外面都有中括號，這說明 ps 無法獲取它們的命令行參數（cmline）。一般來說，ps 的輸出中，名字括在中括號里的，一般都是內核線程。

小結：

Linux 中的中斷處理程序分為上半部和下半部：

• 上半部對應硬件中斷，用來快速處理中斷。
• 下半部對應軟中斷，用來異步處理上半部未完成的工作。
  

6.套路總結篇

6.1cpu使用率高，但是卻找不到CPU高的應用：

（1）使用top查看各個CPU的使用情況，如果找不到CPU使用高的應用；
（2）繼續使用pidstat可以查看每個進程的CPU使用情況；
（3）使用pidstat還是找不到CPU使用高的進程，可以再次觀察top 里面的信息，查看有幾個正在running的進程，如果running的進程數不符合的情況下，再次使用pidstat -p 進程號 查看每個正在running的進行的CPU使用情況；
（4）如果根據第三步找不到running進程的CPU使用情況，可以交叉使用其他的工具查看一下：ps aux | grep 24344，如果還是查看不到CPU的使用情況，那么要查看一下這個進程是不是沒有了。如果查看到該進程還有，但是pid在改變，用 pstree 就可以用樹狀形式顯示所有進程之間的關系：pstree | grep 進程的名字 。還可以用perf record -g 觀察一會兒，然后用perf report 來試着查找具體導致性能問題的函數；
（5）execsnoop 就是一個專為短時進程設計的工具，用 execsnoop 監控上述案例，就可以直接得到 stress 進程的父進程 PID 以及它的命令行參數，並可以發現大量的 stress 進程在不停啟動。

6.2cpu使用率100%，該怎么辦？

（1）使用perf top ,可以實時查看占用CPU最多的進程和函數；
（2）使用perf record -g 和perf report 查看分析性能問題；

6.3系統中出現大量不可中斷進程和僵屍進程怎么辦？

使用top 查看進行的狀態，D狀態為不可中斷進程，可能會導致I/O升高，會導致負載升高。Z狀態為僵屍進行，進行結束沒有被父進程回收。
iowait分析：使用dstat 1 10 ,觀察CPU和I/O的使用情況；
（1）從top命令中找到D狀態的進程pid,然后使用:pidstat -d -p pid 1 3 查看I/O讀寫情況
（2）如果沒有發現異常情況，繼續使用pidstat 去掉進程號，pidstat -d 1 20 來觀察所有進程的I/O使用情況，找到具體導致I/O問題的進程；
（3）找到I/O問題的進程之后，使用strace -p pid 進行跟蹤進程系統調用；如果沒有跟蹤到，看一下進程是否變成了Z狀態的僵屍進程；
（4）進一步使用perf record -g ,等待一會兒之后，使用perf report 定位到我們發現的僵屍進程，按回車鍵展開調用棧，找到導致I/O的函數；
僵屍進程分析：先找到僵屍進程的父進程，然后在父進程里解決。
（1）使用命令：pstree -aps pid 找到父進程，查看父進程的代碼；

6.4.軟中斷 CPU 使用率過高，該怎么辦？

（1）使用top查看CPU的使用情況，如果各個情況都不高，看不出什么問題，查看軟中斷是不是使用了主要cpu;
  (2) 使用watch -d cat /proc/softirqs 查看文件內容的變化情況，查看NET_RX,也就是網絡數據包接收軟中斷的變化速率最快。就從網絡接收的軟中斷着手；
（3）使用sar -n DEV 1 查看網絡收發情況；
   (4)然后分析網絡幀；

6.5 當平均負載高於CPU數量70%的時候，應該分析負載高的問題；

CPU密集型：
（1）使用uptime 查看平均負載；
（2）使用mpstat 查看CPU使用率的變化情況；
（3）使用pidstat -u 5 1 可以找到CPU使用高的進程；
I/O密集型：
（1）watch -d uptime 查看平均負載的變化情況；
（2）mpstat -p ALL 5 1 查看CPU使用率變化情況，查看iowait 變化是否高；
（3）使用pidstat -u 5 1 查看到底是哪個進程導致iowait升高；
大量進程場景：
（1）uptime 查看平均負載；
（2）pidstat -u 5 1查看進程情況；
（3）查看是否是大量超出CPU進程在運行導致CPU過載；

6.6 大量CPU上下文切換；

（1）vmstat 常用來分析CPU上下文切換和中斷次數；
（2）pidstat -w 5 可以查看每個進程上下文切換的情況；
（3）pidstat -wt 1 表示輸出線程上下文切換的指標
（4）watch -d cat /proc/interrupts 觀察中斷變化情況；

6.7 CPU 性能分析的思路圖譜

 

這張圖里，列出了 top、vmstat 和 pidstat分別提供的重要的 CPU 指標，並用虛線表示關聯關系，對應出了性能分析下一步的方向。
通過這張圖你可以發現，這三個命令，幾乎包含了所有重要的 CPU 性能指標，比如：

• 從 top 的輸出可以得到各種 CPU 使用率以及僵屍進程和平均負載等信息。
• 從 vmstat 的輸出可以得到上下文切換次數、中斷次數、運行狀態和不可中斷狀態的進程數。
• 從 pidstat 的輸出可以得到進程的用戶 CPU 使用率、系統 CPU 使用率、以及自願上下文切換和非自願上下文切換情況。

另外，這三個工具輸出的很多指標是相互關聯的，用虛線表示了它們的關聯關系，舉幾個例子你可能會更容易理解。
第一個例子，pidstat 輸出的進程用戶 CPU 使用率升高，會導致 top 輸出的用戶 CPU 使用率升高。所以，當發現 top 輸出的用戶 CPU 使用率有問題時，可以跟 pidstat 的輸出做對比，觀察是否是某個進程導致的問題。
而找出導致性能問題的進程后，就要用進程分析工具來分析進程的行程的行為，比如使用 strace 分析系統調用情況，以及使用perf 分析調用鏈中各級函數的執行情況。
第二個例子，top 輸出的平均負載升高，可以跟 vmstat輸出的運行狀態和不可中斷狀態的進程數做對比，觀察是哪種進程導致的負載升高。

• 如果是不可中斷進程數增多了，那么就需要做 I/O 的分析，也就是用 dstat 或 sar 等工具，進一步分析 I/O的情況。
• 如果是運行狀態進程數增多了，那就需要回到 top 和 pidstat，找出這些處於運行狀態的到底是什么進程，然后再用進程分析工具，做進一步分析。

當發現 top 輸出的軟中斷 CPU 使用率升高時，可以查看 /proc/softirqs 文件中各種類型軟中斷的變化情況，確定到底是哪種軟中斷出的問題。比如，發現是網絡接收中斷導致的問題，那就可以繼續用網絡分析工具 sar 和 tcpdump 來分析。