本文作者：allenxguo，騰訊 QQ 音樂后臺開發工程師
本文主要幫助理解 CPU 相關的性能指標，常見的 CPU 性能問題以及解決方案梳理。
系統平均負載
簡介
系統平均負載：是處于可運行或不可中斷狀態的平均進程數。
可運行進程：使用 CPU 或等待使用 CPU 的進程
不可中斷狀態進程：正在等待某些 IO 訪問，一般是和硬件交互，不可被打斷（不可被打斷的原因是為了保護系統數據一致，防止數據讀取錯誤）
查看系統平均負載
首先top命令查看進程運行狀態，如下：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10760 user 20 0 3061604 84832 5956 S 82.4 0.6 126:47.61 Process
29424 user 20 0 54060 2668 1360 R 17.6 0.0 0:00.03 **top**
程序狀態Status進程可運行狀態為R，不可中斷運行為D（后續講解 top 時會詳細說明）
top查看系統平均負載：
top - 13:09:42 up 888 days, 21:32, 8 users, load average: 19.95, 14.71, 14.01
Tasks: 642 total, 2 running, 640 sleeping, 0 stopped, 0 zombie
%Cpu0 : 37.5 us, 27.6 sy, 0.0 ni, 30.9 id, 0.0 wa, 0.0 hi, 3.6 si, 0.3 st
%Cpu1 : 34.1 us, 31.5 sy, 0.0 ni, 34.1 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
...
KiB Mem : 14108016 total, 2919496 free, 6220236 used, 4968284 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6654506 avail Mem
這里的load average就表示系統最近 1 分鐘、5 分鐘、15 分鐘的系統瓶頸負載。
uptime查看系統瓶頸負載
[root /home/user]# uptime
13:11:01 up 888 days, 21:33, 8 users, load average: 17.20, 14.85, 14.10
查看 CPU 核信息
系統平均負載和 CPU 核數密切相關，我們可以通過以下命令查看當前機器 CPU 信息：
lscpu查看 CPU 信息：
[root@Tencent-SNG /home/user_00]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
...
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0-7 // NUMA架構信息
cat /proc/cpuinfo查看每個 CPU 核的信息：
processor : 7 // 核編號7
vendor_id : GenuineIntel
cpu family : 6
model : 6
...
系統平均負載升高的原因
一般來說，系統平均負載升高意味著 CPU 使用率上升。但是他們沒有必然聯系，CPU 密集型計算任務較多一般系統平均負載會上升，但是如果 IO 密集型任務較多也會導致系統平均負載升高但是此時的 CPU 使用率不一定高，可能很低因為很多進程都處于不可中斷狀態，等待 CPU 調度也會升高系統平均負載。
所以假如我們系統平均負載很高，但是 CPU 使用率不是很高，則需要考慮是否系統遇到了 IO 瓶頸，應該優化 IO 讀寫速度。
所以系統是否遇到 CPU 瓶頸需要結合 CPU 使用率，系統瓶頸負載一起查看（當然還有其他指標需要對比查看，下面繼續講解）
案例問題排查
stress是一個施加系統壓力和壓力測試系統的工具，我們可以使用stress工具壓測試 CPU，以便方便我們定位和排查 CPU 問題。
yum install stress // 安裝stress工具
stress 命令使用
// --cpu 8：8個進程不停的執行sqrt()計算操作
// --io 4：4個進程不同的執行sync()io操作（刷盤）
// --vm 2：2個進程不停的執行malloc()內存申請操作
// --vm-bytes 128M：限制1個執行malloc的進程申請內存大小
stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s
我們這里主要驗證 CPU、IO、進程數過多的問題
CPU 問題排查
使用stress -c 1模擬 CPU 高負載情況，然后使用如下命令觀察負載變化情況：
uptime：使用uptime查看此時系統負載：
# -d 參數表示高亮顯示變化的區域
$ watch -d uptime
... load average: 1.00, 0.75, 0.39
mpstat：使用mpstat -P ALL 1則可以查看每一秒的 CPU 每一核變化信息，整體和top類似，好處是可以把每一秒（自定義）的數據輸出方便觀察數據的變化，最終輸出平均數據：
13:14:53 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:14:58 all 12.89 0.00 0.18 0.00 0.00 0.03 0.00 0.00 0.00 86.91
13:14:58 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
13:14:58 1 0.40 0.00 0.20 0.00 0.00 0.20 0.00 0.00 0.00 99.20
由以上輸出可以得出結論，當前系統負載升高，并且其中 1 個核跑滿主要在執行用戶態任務，此時大多數屬于業務工作。所以此時需要查哪個進程導致單核 CPU 跑滿：
pidstat：使用pidstat -u 1則是每隔 1 秒輸出當前系統進程、CPU 數據：
13:18:00 UID PID %usr %system %guest %CPU CPU Command
13:18:01 0 1 1.00 0.00 0.00 1.00 4 systemd
13:18:01 0 3150617 100.00 0.00 0.00 100.00 0 stress
...
top：當然最方便的還是使用top命令查看負載情況：
top - 13:19:06 up 125 days, 20:01, 3 users, load average: 0.99, 0.63, 0.42
Tasks: 223 total, 2 running, 221 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14.5 us, 0.3 sy, 0.0 ni, 85.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16166056 total, 3118532 free, 9550108 used, 3497416 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6447640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3150617 root 20 0 10384 120 0 R 100.0 0.0 4:36.89 stress
此時可以看到是stress占用了很高的 CPU。
IO 問題排查
我們使用stress -i 1來模擬 IO 瓶頸問題，即死循環執行 sync 刷盤操作： ? uptime：使用uptime查看此時系統負載：
$ watch -d uptime
..., load average: 1.06, 0.58, 0.37
mpstat：查看此時 IO 消耗，但是實際上我們發現這里 CPU 基本都消耗在了 sys 即系統消耗上。
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.33 0.00 12.64 0.13 0.00 0.00 0.00 0.00 0.00 86.90
Average: 0 0.00 0.00 99.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 1 0.00 0.00 0.33 0.00 0.00 0.00 0.00 0.00 0.00 99.67
IO 無法升高的問題：
iowait 無法升高的問題，是因為案例中 stress 使用的是 sync()系統調用，它的作用是刷新緩沖區內存到磁盤中。對于新安裝的虛擬機，緩沖區可能比較小，無法產生大的 IO 壓力，這樣大部分就都是系統調用的消耗了。所以，你會看到只有系統 CPU 使用率升高。解決方法是使用 stress 的下一代 stress-ng，它支持更豐富的選項，比如stress-ng -i 1 --hdd 1 --timeout 600（--hdd 表示讀寫臨時文件）。
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.25 0.00 0.44 26.22 0.00 0.00 0.00 0.00 0.00 73.09
Average: 0 0.00 0.00 1.02 98.98 0.00 0.00 0.00 0.00 0.00 0.00
pidstat：同上（略）
可以看出 CPU 的 IO 升高導致系統平均負載升高。我們使用pidstat查找具體是哪個進程導致 IO 升高的。
top：這里使用 top 依舊是最方面的查看綜合參數，可以得出stress是導致 IO 升高的元兇。
pidstat 沒有 iowait 選項：可能是 centos 默認的sysstat太老導致，需要升級到 11.5.5 之后的版本才可用。
進程數過多問題排查
進程數過多這個問題比較特殊，如果系統運行了很多進程超出了 CPU 運行能，就會出現等待 CPU 的進程。 使用stress -c 24來模擬執行 24 個進程（我的 CPU 是 8 核） uptime：使用uptime查看此時系統負載：
$ watch -d uptime
..., load average: 18.50, 7.13, 2.84
mpstat：同上（略）
pidstat：同上（略）
可以觀察到此時的系統處理嚴重過載的狀態，平均負載高達 18.50。
top：我們還可以使用top命令查看此時Running狀態的進程數，這個數量很多就表示系統正在運行、等待運行的進程過多。
總結
通過以上問題現象及解決思路可以總結出：
- 平均負載高有可能是 CPU 密集型進程導致的
- 平均負載高并不一定代表 CPU 使用率高，還有可能是 I/O 更繁忙了
- 當發現負載高的時候，你可以使用 mpstat、pidstat 等工具，輔助分析負載的來源
總結工具：mpstat、pidstat、top和uptime
CPU 上下文切換
CPU 上下文：CPU 執行每個任務都需要知道任務從哪里加載、又從哪里開始運行，也就是說，需要系統事先幫它設置好 CPU 寄存器和程序計數器（Program Counter，PC）包括 CPU 寄存器在內都被稱為 CPU 上下文。
CPU 上下文切換：CPU 上下文切換，就是先把前一個任務的 CPU 上下文（也就是 CPU 寄存器和程序計數器）保存起來，然后加載新任務的上下文到這些寄存器和程序計數器，最后再跳轉到程序計數器所指的新位置，運行新任務。
CPU 上下文切換：分為進程上下文切換、線程上下文切換以及中斷上下文切換。
進程上下文切換
從用戶態切換到內核態需要通過系統調用來完成，這里就會發生進程上下文切換（特權模式切換），當切換回用戶態同樣發生上下文切換。
一般每次上下文切換都需要幾十納秒到數微秒的 CPU 時間，如果切換較多還是很容易導致 CPU 時間的浪費在寄存器、內核棧以及虛擬內存等資源的保存和恢復上，這里同樣會導致系統平均負載升高。
linux 為每個 CPU 維護一個就緒隊列，將 R 狀態進程按照優先級和等待 CPU 時間排序，選擇最需要的 CPU 進程執行。這里運行進程就涉及了進程上下文切換的時機：
- 進程時間的耗盡。
- 進程在系統資源不足（內存不足）。
- 進程主動sleep。
- 有優先級更高的進程執行。
- 硬中斷發生。
線程上下文切換
線程和進程：
- 當進程只有一個線程時，可以認為進程就等于線程。
- 當進程擁有多個線程時，這些線程會共享相同的虛擬內存和全局變量等資源。這些資源在上下文切換時是不需要修改的。
- 線程也有自己的私有數據，比如棧和寄存器等，這些在上下文切換時也是需要保存的。
所以線程上下文切換包括了 2 種情況：
- 不同進程的線程，這種情況等同于進程切換。
- 通進程的線程切換，只需要切換線程私有數據、寄存器等不共享數據。
中斷上下文切換
中斷處理會打斷進程的正常調度和執行，轉而調用中斷處理程序，響應設備事件。而在打斷其他進程時，就需要將進程當前的狀態保存下來，這樣在中斷結束后，進程仍然可以從原來的狀態恢復運行。
對同一個 CPU 來說，中斷處理比進程擁有更高的優先級，所以中斷上下文切換并不會與進程上下文切換同時發生。由于中斷會打斷正常進程的調度和執行，所以大部分中斷處理程序都短小精悍，以便盡可能快的執行結束。
查看系統上下文切換
vmstat：工具可以查看系統的內存、CPU 上下文切換以及中斷次數：
// 每隔1秒輸出
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 157256 3241604 5144444 0 0 20 0 26503 33960 18 7 75 0 0
17 0 0 159984 3241708 5144452 0 0 12 0 29560 37696 15 10 75 0 0
6 0 0 162044 3241816 5144456 0 0 8 120 30683 38861 17 10 73 0 0
cs：則為每秒的上下文切換次數。
in：則為每秒的中斷次數。
r：就緒隊列長度，正在運行或等待 CPU 的進程。
b：不可中斷睡眠狀態的進程數，例如正在和硬件交互。
pidstat：使用pidstat -w選項查看具體進程的上下文切換次數：
$ pidstat -w -p 3217281 1
10:19:13 UID PID cswch/s nvcswch/s Command
10:19:14 0 3217281 0.00 18.00 stress
10:19:15 0 3217281 0.00 18.00 stress
10:19:16 0 3217281 0.00 28.71 stress
其中cswch/s和nvcswch/s表示自愿上下文切換和非自愿上下文切換。
自愿上下文切換：是指進程無法獲取所需資源，導致的上下文切換。比如說， I/O、內存等系統資源不足時，就會發生自愿上下文切換。
非自愿上下文切換：則是指進程由于時間片已到等原因，被系統強制調度，進而發生的上下文切換。比如說，大量進程都在爭搶 CPU 時，就容易發生非自愿上下文切換
案例問題排查
這里我們使用sysbench工具模擬上下文切換問題。
先使用vmstat 1查看當前上下文切換信息：
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 514540 3364828 5323356 0 0 10 16 0 0 4 1 95 0 0
1 0 0 514316 3364932 5323408 0 0 8 0 27900 34809 17 10 73 0 0
1 0 0 507036 3365008 5323500 0 0 8 0 23750 30058 19 9 72 0 0
然后使用sysbench --threads=64 --max-time=300 threads run模擬 64 個線程執行任務，此時我們再次vmstat 1查看上下文切換信息：
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 318792 3385728 5474272 0 0 10 16 0 0 4 1 95 0 0
1 0 0 307492 3385756 5474316 0 0 8 0 15710 20569 20 8 72 0 0
1 0 0 330032 3385824 5474376 0 0 8 16 21573 26844 19 9 72 0 0
2 0 0 321264 3385876 5474396 0 0 12 0 21218 26100 20 7 73 0 0
6 0 0 320172 3385932 5474440 0 0 12 0 19363 23969 19 8 73 0 0
14 0 0 323488 3385980 5474828 0 0 64 788 111647 3745536 24 61 15 0 0
14 0 0 323576 3386028 5474856 0 0 8 0 118383 4317546 25 64 11 0 0
16 0 0 315560 3386100 5475056 0 0 8 16 115253 4553099 22 68 9 0 0
我們可以明顯的觀察到：
- 當前 cs、in 此時劇增。
- sy+us 的 CPU 占用超過 90%。
- r 就緒隊列長度達到 16 個超過了 CPU 核心數 8 個。
分析 cs 上下文切換問題
我們使用pidstat查看當前 CPU 信息和具體的進程上下文切換信息：
// -w表示查看進程切換信息，-u查看CPU信息，-t查看線程切換信息
$ pidstat -w -u -t 1
10:35:01 UID PID %usr %system %guest %CPU CPU Command
10:35:02 0 3383478 67.33 100.00 0.00 100.00 1 sysbench
10:35:01 UID PID cswch/s nvcswch/s Command
10:45:39 0 3509357 - 1.00 0.00 kworker/2:2
10:45:39 0 - 3509357 1.00 0.00 |__kworker/2:2
10:45:39 0 - 3509702 38478.00 45587.00 |__sysbench
10:45:39 0 - 3509703 39913.00 41565.00 |__sysbench
所以我們可以看到大量的sysbench線程存在很多的上下文切換。
分析 in 中斷問題
我們可以查看系統的watch -d cat /proc/softirqs以及watch -d cat /proc/interrupts來查看系統的軟中斷和硬中斷（內核中斷）。我們這里主要觀察/proc/interrupts即可。
$ watch -d cat /proc/interrupts
RES: 900997016 912023527 904378994 902594579 899800739 897500263 895024925 895452133 Rescheduling interrupts
這里明顯看出重調度中斷（RES）增多，這個中斷表示喚醒空閑狀態 CPU 來調度新任務執行，
總結
- 自愿上下文切換變多了，說明進程都在等待資源，有可能發生了 I/O 等其他問題。
- 非自愿上下文切換變多了，說明進程都在被強制調度，也就是都在爭搶 CPU，說明 CPU 的確成了瓶頸。
- 中斷次數變多了，說明 CPU 被中斷處理程序占用，還需要通過查看/proc/interrupts文件來分析具體的中斷類型。
CPU 使用率
除了系統負載、上下文切換信息，最直觀的 CPU 問題指標就是 CPU 使用率信息。Linux 通過/proc虛擬文件系統向用戶控件提供系統內部狀態信息，其中/proc/stat則是 CPU 和任務信息統計。
$ cat /proc/stat | grep cpu
cpu 6392076667 1160 3371352191 52468445328 3266914 37086 36028236 20721765 0 0
cpu0 889532957 175 493755012 6424323330 2180394 37079 17095455 3852990 0 0
...
這里每一列的含義如下：
- 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），代表以低優先級運行虛擬機的時間。
這里我們可以使用top、ps、pidstat等工具方便的查詢這些數據，可以很方便的看到 CPU 使用率很高的進程，這里我們可以通過這些工具初步定位，但是具體的問題原因還需要其他方法繼續查找。
這里我們可以使用perf top方便查看熱點數據，也可以使用perf record可以將當前數據保存起來方便后續使用perf report查看。
CPU 使用率問題排查
這里總結一下 CPU 使用率問題及排查思路：
- 用戶 CPU 和 Nice CPU 高，說明用戶態進程占用了較多的 CPU，所以應該著重排查進程的性能問題。
- 系統 CPU 高，說明內核態占用了較多的 CPU，所以應該著重排查內核線程或者系統調用的性能問題。
- I/O 等待 CPU 高，說明等待 I/O 的時間比較長，所以應該著重排查系統存儲是不是出現了 I/O 問題。
- 軟中斷和硬中斷高，說明軟中斷或硬中斷的處理程序占用了較多的 CPU，所以應該著重排查內核中的中斷服務程序。
CPU 問題排查套路
CPU 使用率
CPU 使用率主要包含以下幾個方面：
- 用戶 CPU 使用率，包括用戶態 CPU 使用率（user）和低優先級用戶態 CPU 使用率（nice），表示 CPU 在用戶態運行的時間百分比。用戶 CPU 使用率高，通常說明有應用程序比較繁忙。
- 系統 CPU 使用率，表示 CPU 在內核態運行的時間百分比（不包括中斷）。系統 CPU 使用率高，說明內核比較繁忙。
- 等待 I/O 的 CPU 使用率，通常也稱為 iowait，表示等待 I/O 的時間百分比。iowait 高，通常說明系統與硬件設備的 I/O 交互時間比較長。
- 軟中斷和硬中斷的 CPU 使用率，分別表示內核調用軟中斷處理程序、硬中斷處理程序的時間百分比。它們的使用率高，通常說明系統發生了大量的中斷。
- 除在虛擬化環境中會用到的竊取 CPU 使用率（steal）和客戶 CPU 使用率（guest），分別表示被其他虛擬機占用的 CPU 時間百分比，和運行客戶虛擬機的 CPU 時間百分比。
平均負載
反映了系統的整體負載情況，可以查看過去 1 分鐘、過去 5 分鐘和過去 15 分鐘的平均負載。
上下文切換
上下文切換主要關注 2 項指標：
- 無法獲取資源而導致的自愿上下文切換。
- 被系統強制調度導致的非自愿上下文切換。
CPU 緩存命中率
CPU 的訪問速度遠大于內存訪問，這樣在 CPU 訪問內存時不可避免的要等待內存響應。為了協調 2 者的速度差距出現了 CPU 緩存（多級緩存）。 如果 CPU 緩存命中率越高則性能會更好，我們可以使用以下工具查看 CPU 緩存命中率，工具地址、項目地址 perf-tools
# ./cachestat -t
Counting cache functions... Output every 1 seconds.
TIME HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
08:28:57 415 0 0 100.0% 1 191
08:28:58 411 0 0 100.0% 1 191
08:28:59 362 97 0 78.9% 0 8
08:29:00 411 0 0 100.0% 0 9
08:29:01 775 20489 0 3.6% 0 89
08:29:02 411 0 0 100.0% 0 89
08:29:03 6069 0 0 100.0% 0 89
08:29:04 15249 0 0 100.0% 0 89
08:29:05 411 0 0 100.0% 0 89
08:29:06 411 0 0 100.0% 0 89
08:29:07 411 0 3 100.0% 0 89
[...]
總結
通過性能指標查工具(CPU 相關)
性能指標工具說明平均負載uptime
topuptime 簡單展示最近一段時間的平均負載
top 展示更多指標CPU 使用率vmstat
mpstat
top
sar
/proc/stat
top、vmstat、mpstat 只可以動態查看當前，而 sar 可以查看歷史
/proc/stat 是其他性能工具的數據來源進程 CPU 使用率top
pidstat
ps
htop
atop
top、ps 可以以排序方式展示進程 CPU、pidstat 不可排序展示
htop、atop 則以不同顏色展示各類數據更直觀系統上下文切換vmstat展示上下文切換此時、運行狀態、不可中斷狀態進程數量進程上下文切換pidstat展示項很多，包括進程上下文切換信息軟中斷top
/proc/softirqs
mpstattop 可查看軟中斷 CPU 使用率
/proc/softirqs 和 mpstat 則可以查看每個 CPU 上的累計信息硬中斷vmstat
/proc/interruptsvmstat 查看總中斷次數信息
/proc/interrupts 查看各種中斷在每個 CPU 核心上的累計信息網絡dstat
sar
tcpdumpdstat、sar 較詳細的展示出總的網絡收發情況
tcpdump 提供動態抓取數據包的能力IOdstat、sar2 這都提供了詳細的 IO 整體情況CPU 信息/proc/cpuinfo
lscpu都可以查看 CPU 信息系統分析perf
execsnoopperf 分析各種內核函數調用、熱點函數信息
execsnoop 監控短時進程
根據工具查性能指標(CPU 相關)
性能工具CPU 性能指標uptime5、10、15 分鐘內的平均負載展示top平均負載、運行隊列、CPU 各項使用率、進程狀態和 CPU 使用率htoptop 增強版，以不同顏色區分不同類型進程，展示更直觀atopCPU、內存、磁盤、網絡資源全訪問監控，十分齊全vmstat系統整體 CPU 使用率、上下文切換次數、中斷次數，還包括處于運行(r)和不可中斷狀態(b)的進程數量pidstat進程、線程(-t)的每個 CPU 占用信息，中斷上下文切換次數/proc/softirqs展示每個 CPU 上的軟中斷類型及次數/proc/inerrupts展示每個 CPU 上的硬中斷類型及次數ps每個進程的狀態和 CPU 使用率pstree進程的父子關系展示dstat系統整體 CPU 使用率(以及相關 IO、網絡信息)sar系統整體 CPU 使用率，以及使用率歷史信息strace跟蹤進程的系統調用perfCPU 性能事件分析，例如：函數調用鏈、CPU 緩存命中率、CPU 調度等execsnoop短時進程分析
CPU 問題排查方向
有了以上性能工具，在實際遇到問題時我們并不可能全部性能工具跑一遍，這樣效率也太低了，所以這里可以先運行幾個常用的工具 top、vmstat、pidstat 分析系統大概的運行情況然后在具體定位原因。
top 系統CPU => vmstat 上下文切換次數 => pidstat 非自愿上下文切換次數 => 各類進程分析工具(perf strace ps execsnoop pstack)
top 用戶CPU => pidstat 用戶CPU => 一般是CPU計算型任務
top 僵尸進程 => 各類進程分析工具(perf strace ps execsnoop pstack)
top 平均負載 => vmstat 運行狀態進程數 => pidstat 用戶CPU => 各類進程分析工具(perf strace ps execsnoop pstack)
top 等待IO CPU => vmstat 不可中斷狀態進程數 => IO分析工具(dstat、sar -d)
top 硬中斷 => vmstat 中斷次數 => 查看具體中斷類型(/proc/interrupts)
top 軟中斷 => 查看具體中斷類型(/proc/softirqs) => 網絡分析工具(sar -n、tcpdump) 或者 SCHED(pidstat 非自愿上下文切換)
CPU 問題優化方向
性能優化往往是多方面的，CPU、內存、網絡等都是有關聯的，這里暫且給出 CPU 優化的思路，以供參考。
程序優化
- 基本優化：程序邏輯的優化比如減少循環次數、減少內存分配，減少遞歸等等。
- 編譯器優化：開啟編譯器優化選項例如gcc -O2對程序代碼優化。
- 算法優化：降低了研發復雜度，例如使用nlogn的排序算法，使用logn的查找算法等。
- 異步處理：例如把輪詢改為通知方式
- 多線程代替多進程：某些場景下多線程可以代替多進程，因為上下文切換成本較低
- 緩存：包括多級緩存的使用（略）加快數據訪問
系統優化
- CPU 綁定：綁定到一個或多個 CPU 上，可以提高 CPU 緩存命中率，減少跨 CPU 調度帶來的上下文切換問題
- CPU 獨占：跟 CPU 綁定類似，進一步將 CPU 分組，并通過 CPU 親和性機制為其分配進程。
- 優先級調整：使用 nice 調整進程的優先級，適當降低非核心應用的優先級，增高核心應用的優先級，可以確保核心應用得到優先處理。
- 為進程設置資源限制：使用 Linux cgroups 來設置進程的 CPU 使用上限，可以防止由于某個應用自身的問題，而耗盡系統資源。
- NUMA 優化：支持 NUMA 的處理器會被劃分為多個 Node，每個 Node 有本地的內存空間，這樣 CPU 可以直接訪問本地空間內存。
- 中斷負載均衡：無論是軟中斷還是硬中斷，它們的中斷處理程序都可能會耗費大量的 CPU。開啟 irqbalance 服務或者配置 smp_affinity，就可以把中斷處理過程自動負載均衡到多個 CPU 上。
參考
極客時間：Linux 性能優化實戰
