05-基礎篇：某個應用的CPU使用率居然達到100%，我該怎麼辦？
阿新 • • 發佈：2021-11-10
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# 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等工具，排查出引起效能問題的具體函式
轉載請註明出處喲~ https://www.cnblogs.com/lichengguo