CPU 性能指標

最容易想到的應該是 CPU 使用率，這也是實際環(huán)境中最常見的一個性能指標。

CPU 使用率描述了非空閑時間占總 CPU 時間的百分比，根據 CPU 上運行任務的不同，又被分為用戶 CPU、系統 CPU、等待 I/O CPU、軟中斷和硬中斷等。

用戶 CPU 使用率，包括用戶態(tài) CPU 使用率（user）和低優(yōu)先級用戶態(tài) CPU 使用率（nice），表示 CPU 在用戶態(tài)運行的時間百分比。

用戶 CPU 使用率高，通常說明有應用程序比較繁忙。

系統 CPU 使用率，表示 CPU 在內核態(tài)運行的時間百分比（不包括中斷）。系統 CPU 使用率高，說明內核比較繁忙。

等待 I/O 的 CPU 使用率，通常也稱為 iowait，表示等待 I/O 的時間百分比。iowait 高，通常說明系統與硬件設備的 I/O 交互時間比較長。

軟中斷和硬中斷的 CPU 使用率，分別表示內核調用軟中斷處理程序、硬中斷處理程序的時間百分比。它們的使用率高，通常說明系統發(fā)生了大量的中斷。

還有在虛擬化環(huán)境中會用到的竊取 CPU 使用率（steal）和客戶 CPU 使用率（guest），分別表示被其他虛擬機占用的 CPU 時間百分比，和運行客戶虛擬機的 CPU 時間百分比。

應該是平均負載（Load Average），也就是系統的平均活躍進程數。

它反應了系統的整體負載情況，主要包括三個數值，分別指過去 1 分鐘、過去 5 分鐘和過去 15 分鐘的平均負載。理想情況下，平均負載等于邏輯 CPU 個數，這表示每個 CPU 都恰好被充分利用。如果平均負載大于邏輯 CPU 個數，就表示負載比較重了。

第三個，進程上下文切換。

無法獲取資源而導致的自愿上下文切換；被系統強制調度導致的非自愿上下文切換。

上下文切換，本身是保證 Linux 正常運行的一項核心功能。但過多的上下文切換，會將原本運行進程的 CPU 時間，消耗在寄存器、內核棧以及虛擬內存等數據的保存和恢復上，縮短進程真正運行的時間，成為性能瓶頸。

還有一個指標，CPU 緩存的命中率。

由于 CPU 發(fā)展的速度遠快于內存的發(fā)展，CPU 的處理速度就比內存的訪問速度快得多。這樣，CPU 在訪問內存的時候，免不了要等待內存的響應。為了協調這兩者巨大的性能差距，CPU 緩存（通常是多級緩存）就出現了。

這張圖顯示的，CPU 緩存的速度介于 CPU 和內存之間，緩存的是熱點的內存數據。根據不斷增長的熱點數據，這些緩存按照大小不同分為 L1、L2、L3 等三級緩存，其中 L1 和 L2 常用在單核中， L3 則用在多核中。

從 L1 到 L3，三級緩存的大小依次增大，相應的，性能依次降低（當然比內存還是好得多）。而它們的命中率，衡量的是 CPU 緩存的復用情況，命中率越高，則表示性能越好。

性能工具

首先，平均負載的案例。先用 uptime， 查看了系統的平均負載；而在平均負載升高后，又用 mpstat 和 pidstat ，分別觀察了每個 CPU 和每個進程 CPU 的使用情況，進而找出了導致平均負載升高的進程。

先用 vmstat ，查看了系統的上下文切換次數和中斷次數；然后通過 pidstat ，觀察了進程的自愿上下文切換和非自愿上下文切換情況；最后通過 pidstat ，觀察了線程的上下文切換情況，找出了上下文切換次數增多的根源。

進程 CPU 使用率升高的案例。先用 top ，查看了系統和進程的 CPU 使用情況，發(fā)現 CPU 使用率升高的進程是 php-fpm；再用 perf top ，觀察 php-fpm 的調用鏈，最終找出 CPU 升高的根源，也就是庫函數 sqrt() 。

系統的 CPU 使用率升高的案例。我們先用 top 觀察到了系統 CPU 升高，但通過 top 和 pidstat ，卻找不出高 CPU 使用率的進程。于是，重新審視 top 的輸出，又從 CPU 使用率不高但處于 Running 狀態(tài)的進程入手，找出了可疑之處，最終通過 perf record 和 perf report ，發(fā)現原來是短時進程在搗鬼。

對于短時進程，我還介紹了一個專門的工具 execsnoop，它可以實時監(jiān)控進程調用的外部命令。

不可中斷進程和僵尸進程的案例。我們先用 top 觀察到了 iowait 升高的問題，并發(fā)現了大量的不可中斷進程和僵尸進程；接著用 dstat 發(fā)現是這是由磁盤讀導致的，于是又通過 pidstat 找出了相關的進程。但我們用 strace 查看進程系統調用卻失敗了，最終還是用 perf 分析進程調用鏈，才發(fā)現根源在于磁盤直接 I/O

軟中斷的案例。通過 top 觀察到，系統的軟中斷 CPU 使用率升高；接著查看 /proc/softirqs， 找到了幾種變化速率較快的軟中斷；然后通過 sar 命令，發(fā)現是網絡小包的問題，最后再用 tcpdump ，找出網絡幀的類型和來源，確定是一個 SYN FLOOD 攻擊導致的。

把性能指標和性能工具聯系起來第一個維度，從 CPU 的性能指標出發(fā)。也就是說，當要查看某個性能指標時，要清楚知道哪些工具可以做到。

根據不同的性能指標，對提供指標的性能工具進行分類和理解

用 top 發(fā)現了軟中斷 CPU 使用率高后，下一步自然就想知道具體的軟中斷類型。查看proc 文件系統中的 /proc/softirqs 這個文件。找到的軟中斷類型是網絡接收，那就要繼續(xù)往網絡接收方向思考。用的正是 dstat查看網絡報文接收情況

第二個維度，從工具出發(fā)。也就是當已經安裝了某個工具后，要知道這個工具能提供哪些指標。

這在實際環(huán)境特別是生產環(huán)境中也是非常重要的，因為很多情況下，你并沒有權限安裝新的工具包，只能最大化地利用好系統中已經安裝好的工具，這就需要你對它們有足夠的了解。具體到每個工具的使用方法，一般都支持豐富的配置選項。不過不用擔心，這些配置選項并不用背下來。你只要知道有哪些工具、以及這些工具的基本功能是什么就夠了。真正要用到的時候， 通過 man 命令，查它們的使用手冊就可以了。

迅速分析 CPU 的性能瓶頸

在實際生產環(huán)境中，通常都希望盡可能快地定位系統的瓶頸，然后盡可能快地優(yōu)化性能，也就是要又快又準地解決性能問題。

雖然 CPU 的性能指標比較多，但要知道，既然都是描述系統的 CPU 性能，它們就不會是完全孤立的，很多指標間都有一定的關聯。想弄清楚性能指標的關聯性，就要通曉每種性能指標的工作原理。

用戶 CPU 使用率高，應該去排查進程的用戶態(tài)而不是內核態(tài)。因為用戶 CPU 使用率反映的就是用戶態(tài)的 CPU 使用情況，而內核態(tài)的 CPU 使用情況只會反映到系統 CPU 使用率上。有這樣的基本認識，就可以縮小排查的范圍，省時省力。

所以，為了縮小排查范圍，通常會先運行幾個支持指標較多的工具，如 top、vmstat 和 pidstat

這三個命令，幾乎包含了所有重要的 CPU 性能指標，比如：從 top 的輸出可以得到各種 CPU 使用率以及僵尸進程和平均負載等信息。從 vmstat 的輸出可以得到上下文切換次數、中斷次數、運行狀態(tài)和不可中斷狀態(tài)的進程數。從 pidstat 的輸出可以得到進程的用戶 CPU 使用率、系統 CPU 使用率、以及自愿上下文切換和非自愿上下文切換情況。

pidstat 輸出的進程用戶 CPU 使用率升高，會導致 top 輸出的用戶 CPU 使用率升高。所以，當發(fā)現 top 輸出的用戶 CPU 使用率有問題時，可以跟 pidstat 的輸出做對比，觀察是否是某個進程導致的問題。而找出導致性能問題的進程后，就要用進程分析工具來分析進程的行為，比如使用 strace 分析系統調用情況，以及使用 perf 分析調用鏈中各級函數的執(zhí)行情況。

top 輸出的平均負載升高，可以跟 vmstat 輸出的運行狀態(tài)和不可中斷狀態(tài)的進程數做對比，觀察是哪種進程導致的負載升高。

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

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

總結

以上是生活随笔為你收集整理的快速定位问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。