CPU使用率概念
Linux作為一個多任務操作系統，將每個CPU的時間划分為很短的時間片，再通過調度器輪流分配給各個任務使用，因此造成多任務同時運行的錯覺
為了維護CPU時間，Linux通過事先定義的節拍率（內核中表示為HZ），觸發時間中斷
並使用全局變量Jiffies記錄了開機以來的節拍數。每發生一次時間中斷，Jiffies的值就加1
節拍率HZ是內核的可配選項，可以設置為100、250、1000等
不同的系統可能設置不同數值，可以通過查詢/boot/config內核選項來查看它的配置值
比如在我的系統中，節拍率設置成了1000，也就是每秒鍾觸發1000次時間中斷
[root@local_sa_192-168-1-6 ~]# grep "CONFIG_HZ=" /boot/config-`uname -r`
CONFIG_HZ=1000
同時，正因為節拍率HZ是內核選項，所以用戶空間程序並不能直接訪問
為了方便用戶空間程序，內核還提供了一個用戶空間節拍率USER_HZ
它總是固定為100，也就是1/100秒
這樣，用戶空間程序並不需要關心內核中HZ被設置成了多少，因為它看到的總是固定值USER_HZ
Linux通過/proc虛擬文件系統，向用戶空間提供了系統內部狀態的信息
而/proc/stat提供的就是系統的CPU和任務統計信息
比方說，如果只關注CPU的話，可以執行下面的命令
[root@local_sa_192-168-1-6 ~]# cat /proc/stat |grep ^cpu
cpu 253484 65 138912 33981119 60959 0 187 1363 0 0
cpu0 145515 28 70112 16971015 28062 0 106 619 0 0
cpu1 107969 37 68799 17010103 32897 0 81 744 0 0
第一列表示的是CPU編號，如cpu0、cpu1
第一行沒有編號的cpu，表示的是所有CPU的累加
其他列則表示不同場景下CPU的累加節拍數，它的單位是USER_HZ，也就是10 ms（1/100秒）
所以這其實就是不同場景下的CPU時間
user（通常縮寫為us），代表用戶態CPU時間，它不包括下面的nice時間，但包括了guest時間
nice（通常縮寫為ni），代表低優先級用戶態CPU時間，也就是進程的nice值被調整為1-19之間時的CPU時間，nice可取值范圍是-20到19，數值越大，優先級反而越低
system（通常縮寫為sys），代表內核態CPU時間
idle（通常縮寫為id），代表空閑時間，它不包括等待I/O的時間（iowait）
iowait（通常縮寫為wa），代表等待I/O的CPU時間
irq（通常縮寫為hi），代表處理硬中斷的CPU時間
softirq（通常縮寫為 si），代表處理軟中斷的CPU時間
steal（通常縮寫為st），代表當系統運行在虛擬機中的時候，被其他虛擬機占用的CPU時間
guest（通常縮寫為guest），代表通過虛擬化運行其他操作系統的時間，也就是運行虛擬機的CPU時間
guest_nice（通常縮寫為gnice），代表以低優先級運行虛擬機的時間
而我們通常所說的CPU使用率，就是除了空閑時間外的其他時間占總CPU時間的百分比，用公式來表示就是
根據這個公式，就可以從/proc/stat中的數據，很容易地計算出CPU使用率
當然，也可以用每一個場景的CPU時間，除以總的CPU時間，計算出每個場景的CPU使用率
不過先不要着急計算，直接用/proc/stat的數據，這是開機以來的節拍數累加值
所以直接算出來的，是開機以來的平均CPU使用率，一般沒啥參考價值
事實上，為了計算CPU使用率，性能工具一般都會取間隔一段時間（比如3秒）的兩次值，作差后，再計算出這段時間內的平均CPU使用率
這個公式，就是我們用各種性能工具所看到的CPU使用率的實際計算方法
現在，我們知道了系統CPU使用率的計算方法，那進程的呢？
跟系統的指標類似，Linux也給每個進程提供了運行情況的統計信息
也就是/proc/[pid]/stat
不過，這個文件包含的數據就比較豐富了，總共有52列的數據
那么查看CPU使用率，就必須先讀取/proc/stat和/proc/[pid]/stat這兩個文件，然后再按照上面的公式計算出來呢？
當然不是，各種各樣的性能分析工具已經幫我們計算好了
不過要注意的是，性能分析工具給出的都是間隔一段時間的平均CPU使用率
所以要注意間隔時間的設置，特別是用多個工具對比分析時，一定要保證它們用的是相同的間隔時間
比如，對比一下top和ps這兩個工具報告的CPU使用率，默認的結果很可能不一樣
因為top默認使用3秒時間間隔，而ps使用的卻是進程的整個生命周期
[root@local_sa_192-168-1-6 ~]# ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
......
0 R 0 15751 12605 0 80 0 - 38311 - pts/0 00:00:00 ps
# C CPU 使用的資源百分比
怎么查看CPU使用率
查看CPU使用率常用工具
【top】顯示了系統總體的CPU和內存使用情況，以及各個進程的資源使用情況
【ps】則只顯示了每個進程的資源使用情況
[root@local_sa_192-168-1-6 ~]# top
top - 15:57:52 up 2 days, 3 min, 1 user, load average: 0.00, 0.01, 0.05
Tasks: 177 total, 1 running, 176 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 0.0 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
......
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14687 root 20 0 164104 2324 1568 R 0.3 0.1 0:00.01 top
......
第三行%Cpu就是系統的CPU使用率
top默認顯示的是所有CPU的平均值，這個時候你只需要按下數字1，就可以切換到每個CPU的使用率了
空白行之后是進程的實時信息，每個進程都有一個%CPU列，表示進程的CPU使用率
它是用戶態和內核態CPU使用率的總和，包括進程用戶空間使用的CPU、通過系統調用執行的內核空間CPU 、
以及在就緒隊列等待運行的CPU，在虛擬化環境中，它還包括了運行虛擬機占用的CPU
到這里我們可以發現，top並沒有細分進程的用戶態CPU和內核態CPU。那要怎么查看每個進程的詳細情況呢？
【pidstat】正是一個專門分析每個進程CPU使用情況的工具
# 每隔1秒輸出一組數據，共輸出5組
[root@local_sa_192-168-1-6 ~]# pidstat 1 5
Linux 3.10.0-1160.31.1.el7.x86_64 (local_sa_192-168-1-6) 2021年11月10日 _x86_64_ (2 CPU)
16時01分01秒 UID PID %usr %system %guest %wait %CPU CPU Command
16時01分02秒 0 14851 0.00 0.99 0.00 0.00 0.99 1 pidstat
# 輸出結果分析
# 用戶態CPU使用率 （%usr）
# 內核態CPU使用率（%system）
# 運行虛擬機CPU使用率（%guest）
# 等待CPU使用率（%wait）
# 以及總的 CPU 使用率（%CPU）
CPU使用率過高怎么辦?
通過top、ps、pidstat等工具，能夠輕松找到CPU使用率較高（比如100%）的進程
那么占用CPU的到底是代碼里的哪個函數呢？
只有找到它，才能更高效、更針對性地進行優化
GDB（The GNU Project Debugger），這個功能強大的程序調試利器
的確，GDB在調試程序錯誤方面很強大
但是，GDB並不適合在性能分析的早期應用
因為GDB調試程序的過程會中斷程序運行，這在線上環境往往是不允許的
所以，GDB只適合用在性能分析的后期，當找到了出問題的大致函數后，線下再借助它來進一步調試函數內部的問題
【perf】是Linux 2.6.31以后內置的性能分析工具
它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題
【perf】分析CPU性能問題，兩種最常見的用法
# 第一種方法
perf top，類似於top，它能夠實時顯示占用CPU時鍾最多的函數或者指令，因此可以用來查找熱點函數
[root@local_sa_192-168-1-6 ~]# perf top
Samples: 1K of event 'cpu-clock', 4000 Hz, Event count (approx.): 251812500 lost: 0/0 drop: 0/0
Overhead Shared Object Symbol
12.68% [kernel] [k] module_get_kallsym
10.34% [kernel] [k] vsnprintf
7.91% [kernel] [k] format_decode
6.08% [kernel] [k] kallsyms_expand_symbol.constprop.1
4.86% [kernel] [k] number.isra.2
3.47% perf [.] rb_next
# 輸出結果
# 第一行包含三個數據，分別是采樣數（Samples）、事件類型（event）和事件總數量（Event count）
# 比如這個例子中，perf總共采集了1000個CPU時鍾事件，而總事件數則為251812500
# 另外，采樣數需要我們特別注意。如果采樣數過少（比如只有十幾個），那下面的排序和百分比就沒什么實際參考價值了
# 再往下看是一個表格式樣的數據，每一行包含四列，分別是
# 第一列Overhead ，是該符號的性能事件在所有采樣中的比例，用百分比來表示
# 第二列Shared ，是該函數或指令所在的動態共享對象（Dynamic Shared Object），如內核、進程名、動態鏈接庫名、內核模塊名等
# 第三列Object ，是動態共享對象的類型。比如[.]表示用戶空間的可執行程序、或者動態鏈接庫，而[k]則表示內核空間
# 最后一列Symbol是符號名，也就是函數名。當函數名未知時，用十六進制的地址來表示
# 第二種方法
perf record和perf report
perf top雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者后續的分析
perf record則提供了保存數據的功能，保存后的數據，用perf report解析展示
# 按Ctrl+C終止采樣(會在運行該命令的目錄下生成perf.data)
[root@local_sa_192-168-1-6 ~]# perf record
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ]
[root@local_sa_192-168-1-6 ~]# ls -l
-rw------- 1 root root 5493628 11月 10 15:04 perf.data
[root@local_sa_192-168-1-6 ~]# perf report # 展示類似於perf top的報告
在實際使用中，我們還經常為perf top和perf record加上-g參數，
開啟調用關系的采樣，方便我們根據調用鏈來分析性能問題
案例
以Nginx+PHP的Web服務為例，當發現CPU使用率過高的問題后，要怎么使用top等工具找出異常的進程
又要怎么利用perf找出引發性能問題的函數
實驗環境
# 服務端（192.168.1.6）
配置：2CPU，4G內存，centos7.6_64
預先安裝docker、sysstat、perf、ab 等工具（yum install perf httpd-tools sysstat -y）
# 客戶端（192.168.1.5）
配置：1CPU，2G內存，centos7.6_64
預先安裝ab工具（yum install httpd-tools -y）
ab（apache bench）是一個常用的HTTP服務性能測試工具，這里用來模擬Ngnix的客戶端
由於Nginx和PHP的配置比較麻煩，我把它們打包成了兩個Docker鏡像，這樣只需要運行兩個容器，就可以得到模擬環境
例要用到兩台虛擬機，如下圖所示
一台用作Web服務器，來模擬性能問題
另一台用作Web服務器的客戶端，來給Web服務增加壓力請求
1.在服務端，打開第一個終端執行下面的命令來運行 Nginx 和 PHP 應用
[root@local_sa_192-168-1-6 ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx
[root@local_sa_192-168-1-6 ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
[root@local_sa_192-168-1-6 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1fbc1bb55c00 feisky/php-fpm "php-fpm -F --pid /o…" 2 hours ago Up 2 hours phpfpm
558cc67e5df8 feisky/nginx "nginx -g 'daemon of…" 2 hours ago Up 2 hours 0.0.0.0:10000->80/tcp, :::10000->80/tcp nginx
2.在服務端，第二個終端使用curl訪問http://[VM1 的 IP]:10000，確認 Nginx 已正常啟動
[root@local_sa_192-168-1-6 ~]# curl http://192.168.1.6:10000/
It works!
3.在客戶端，測試一下這個Nginx服務的性能，在第二個終端運行下面的ab命令
# 並發10個請求測試Nginx性能，總共測試100個請求
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 100 http://192.168.1.6:10000/
......
Requests per second: 24.05 [#/sec] (mean)
Time per request: 415.757 [ms] (mean)
......
從ab的輸出結果我們可以看到，
Nginx能承受的每秒平均請求數只有24.05
這也太差了吧。那到底是哪里出了問題呢
我們用top和 pidstat 再來觀察下
4.在客戶端，將測試的請求總數增加到 10000
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 10000 http://192.168.1.6:10000/
5.在服務端，運行top命令，並按下數字1 ，切換到每個CPU的使用率
[root@local_sa_192-168-1-6 ~]# top
...
%Cpu0 : 98.7 us, 1.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 99.3 us, 0.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21514 daemon 20 0 336696 16384 8712 R 41.9 0.2 0:06.00 php-fpm
21513 daemon 20 0 336696 13244 5572 R 40.2 0.2 0:06.08 php-fpm
21515 daemon 20 0 336696 16384 8712 R 40.2 0.2 0:05.67 php-fpm
21512 daemon 20 0 336696 13244 5572 R 39.9 0.2 0:05.87 php-fpm
21516 daemon 20 0 336696 16384 8712 R 35.9 0.2 0:05.61 php-fpm
這里可以看到，系統中有幾個php-fpm進程的CPU使用率加起來接近200%
而每個CPU的用戶使用率（us）也已經超過了98%，接近飽和
可以確認，正是用戶空間的php-fpm進程，導致CPU使用率驟升
6.在服務端，運行 perf命令（這里選擇第二種方法，因為第一種方法在centos上有問題）
6.1第一種方法
[root@local_sa_192-168-1-6 tmp]# perf top -g -p 21514
# 從下圖可以看到，函數名稱顯示為十六進制了，不可讀。這個是在centos上才有的問題，Ubuntu上沒有該問題
# 所以選擇第二種方法
6.1第二種方法
#先運行命令，然后等待15s終止該命令
[root@local_sa_192-168-1-6 ~]# perf record -g -p 21514
[root@local_sa_192-168-1-6 ~]# ls -l
-rw------- 1 root root 5493628 11月 10 15:04 perf.data
# 因為實驗環境是容器環境，所以要把perf.data拷貝到容器中去解析
[root@local_sa_192-168-1-6 ~]# docker cp perf.data phpfpm:/tmp
[root@local_sa_192-168-1-6 ~]# docker exec -i -t phpfpm bash
root@2e2f18f5ba75:/app# cd /tmp/
root@2e2f18f5ba75:/tmp# apt-get update && apt-get install -y linux-perf linux-tools procps
root@2e2f18f5ba75:/tmp# chown root.root perf.data
root@2e2f18f5ba75:/tmp# perf_4.9 report
# 注意：最后運行的工具名字是容器內部安裝的版本perf_4.9，而不是perf命令
這是因為perf會去跟內核的版本進行匹配
但鏡像里面安裝的perf版本有可能跟虛擬機的內核版本不一致。
注意：上面的問題只是在centos系統中有問題，ubuntu上沒有這個問題
按回車鍵可以逐層打開
可以發現調用關系最終到了sqrt和add_function
看來，需要從這兩個函數入手了
7.在服務端，拷貝出Nginx應用的源碼，看看是不是調用了這兩個函數
# 從容器phpfpm中將PHP源碼拷貝出來
[root@local_sa_192-168-1-6 ~]# docker cp phpfpm:/app .
# 使用grep查找函數調用
[root@local_sa_192-168-1-6 ~]# grep sqrt -r app/ #找到了sqrt調用
app/index.php: $x += sqrt($x);
#沒找到add_function調用，這其實是PHP內置函數
[root@local_sa_192-168-1-6 ~]# grep add_function -r app/
# 查看代碼，最終定位到有問題的代碼函數
[root@local_sa_192-168-1-6 ~]# cat app/index.php
<?php
// test only.
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "It works!"
8.在服務端，修復
# 停止原來的應用
[root@local_sa_192-168-1-6 ~]# docker rm -f nginx phpfpm
# 運行優化后的應用
[root@local_sa_192-168-1-6 ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx:cpu-fix
[root@local_sa_192-168-1-6 ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:cpu-fix
9.在客戶端，再次測試
[root@local_deploy_192-168-1-5 ~]# ab -c 10 -n 10000 http://192.168.1.6:10000/
......
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1720000 bytes
HTML transferred: 90000 bytes
Requests per second: 3718.75 [#/sec] (mean)
Time per request: 2.689 [ms] (mean)
可以發現，現在每秒的平均請求數，變成了3718
小結
CPU使用率是最直觀和最常用的系統性能指標，更是我們在排查性能問題時，通常會關注的第一個指標
所以我們更要熟悉它的含義，尤其要弄清楚用戶（%user）、Nice（%nice）、系統（%system）
等待I/O（%iowait） 、中斷（%irq）以及軟中斷（%softirq）這幾種不同CPU的使用率
1.用戶CPU和Nice的CPU高，說明用戶態進程占用了較多的CPU，所以應該着重排查進程的性能問題
2.系統CPU高，說明內核態占用了較多的CPU，所以應該着重排查內核線程或者系統調用的性能問題
3.I/O等待CPU高，說明等待I/O的時間比較長，所以應該着重排查系統存儲是不是出現了I/O問題
4.軟中斷和硬中斷高，說明軟中斷或硬中斷的處理程序占用了較多的CPU，所以應該着重排查內核中的中斷服務程序
碰到CPU使用率升高的問題，你可以借助top、pidstat等工具，確認引發CPU性能問題的來源
再使用perf等工具，排查出引起性能問題的具體函數