軟體性能測試（連載7）

2020 年 2 月 19 日
筆記

6）CPU狀態轉換

CPU狀態轉換如圖3-18所示。

圖3-18 CPU狀態轉換圖

7）軟中斷與硬中斷

假設現在一家公司就有一名客服人員，這個客服人員就有一台座機，這種情況下用戶碰到問題只能打電話給這個客服人員，如果有多個用戶同時打入只能憑運氣，先打通電話的人得到回答，其他人只能依次等待。顯然這種處理機制是非常低效的，小公司可能還可以，大一點的公司就不行了。於是現在共有4-5位客服人員，建立總分機架構，1位負責總機（也可以交給語音提示來操作），負責把問題分給4個分機，讓4個分機人員來處理具體的問題，這樣一來效率就明顯提高了。如果客戶來電，總機負責人接電話分給分機人員（或通過語音提示用戶撥打分機號）叫做硬中斷，而分機負責人處理具體問題叫做軟中斷。Linux的CPU正是採用硬中斷與軟中斷結合的方式來處理問題的。比如現在網卡告訴CPU，有一批數據要從網路中過來，希望系統做好接收準備，CPU手頭的工作被打斷（中斷），將網路上的數據存儲在暫存器中，然後呼起一個進程來處理後續操作，就回頭處理剛才中斷之前的工作了。被呼起的進程可以在後台「慢慢地」地把暫存器中的數據按照規定格式寫入資料庫中。這裡CPU處理的過程就為硬中斷過程，而進程把數據寫入資料庫中過程為軟中斷過程。具體如圖3-19所示。

圖3-19 軟中斷與硬中斷

硬中斷可以用命令cat /proc/interrupts來查看，而軟中斷可以用cat /proc/softirqs來查看。由於硬中斷比軟中斷過程短得多，所以作為性能監控往往需要監控軟中斷。

#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

其中。

•TIMER。

定時產生的軟中斷。

•NET_RX。

網路接收產生的軟中斷。

•NET_TX。

網路發送產生的軟中斷。

•SCHED。

內核調度產生的軟中斷。

•RCU。

RCU產生的軟中斷。

擴展閱讀：RCU[32]RCU(Read-Copy Update)，顧名思義就是讀/拷貝/修改。對於被RCU保護的共享數據結構，不需要獲得任何鎖就可以訪問它，但寫者在訪問它時首先拷貝一個副本，然後對副本進行修改，最後使用一個回調（callback）機制在適當的時機把指向原來數據的指針重新指向新的被修改的數據。這個時機就是所有引用該數據的CPU都退出對共享數據的操作

另外也經常使用ps aux | grep softirq命令來查看產生中斷進程。

#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]

注意：有[]為內核進程，可見軟中斷進程屬於內核進程。

在top命令中也可以看到軟中斷進程。

#top

top – 10:50:58 up 1 days, 22:10, 1 user, load average: 0.00, 0.00, 0.00

Tasks: 122 total, 1 running, 71 sleeping, 0 stopped, 0 zombie

%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 3.3 si, 0.0 st

%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st

…

PIDUSER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7 root 20 0 0 0 0 S 0.3 0.0 0:01.64 ksoftirqd/0

16 root 20 0 0 0 0 S 0.3 0.0 0:01.97 ksoftirqd/1

2663root 20 0 923480 28292 13996S 0.3 0.3 4:58.66 docker-containe

3699root 20 0 0 0 0 I 0.3 0.0 0:00.13 kworker/u4:0

3708root 20 0 44572 4176 3512 R 0.3 0.1 0:00.07 top

1root 20 0 225384 9136 6724 S 0.0 0.1 0:23.25 systemd

2root 20 0 0 0 0 S 0.0 0.0 0:00.03 kthreadd

除了可以使用cat /proc/softirqs查看當前軟中斷狀態，在實際工作中也常常使用watch -d cat /proc/softirqs來動態顯示實時軟中斷狀態。

案例3-12：小包問題

#watch -d cat /proc/softirqs

CPU0 CPU1

HI: 0 0

TIMER: 1083906 2368646

NET_TX: 53 9

NET_RX: 1550643 1916776

BLOCK: 0 0

IRQ_POLL:0 0

TASKLET: 333637 3930

SCHED: 963675 2293171

HRTIMER: 0 0

RCU: 1542111 1590625

上面結果中可以看出，網路發送產生了大量軟中斷。然後通過sar -n DEV 1命令來進一步分析。

#sar -n DEV 1

15:03:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil

15:03:47eth0 35645.00 6304.00 857.43 358.11 0.00 0.00 0.00 0.01

15:03:47docker0 6302.00 12604.00 270.79 664.66 0.00 0.00 0.00 0.00

15:03:47 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

15:03:47 veth9f6bbcd6302.00 12604.00 356.95 664.66 0.00 0.00 0.00 0.05

在這裡。

•15:03:46。

表示報告的時間。

•IFACE。

表示網卡名。

•rxpck/s和txpck/s。

分別表示每秒接收、發送的網路幀數，也就是PPS。

•rxkB/s和txkB/s

分別表示每秒接收、發送的千位元組數，也就是BPS。

在上面結果中，857（txpck/s）×1024/35645（rxpck/s）= 24位元組，說明平均每個網路幀只有24位元組，這顯然是很小的網路幀，也就是通常所說的小包問題。確定是小包是問題後，就可以使用類似tcpdump工具進行進一步排查了。

8）CPU使用率

•CPU使用率=1-CPU空閑時間/CPU總時間。

•平均CPU使用率=1- (CPU空閑時間New- CPU空閑時間Old)/ (CPU總時間New- CPU總時間Old)。

top命令顯示了系統總體的CPU和記憶體使用情況，以及各個進程的資源使用情況。而ps命令則只顯示了每個進程的資源使用情況。

9）CPU節拍率

CPU節拍率指每秒鐘CPU切換的次數，單位為HZ。一般為：100HZ、250HZ、1000HZ，如果CPU節拍率為250HZ，表示：每秒鐘觸發250次切換，即每次切換持續1/250s。CPU節拍率可以通過grep 'CONFIG_HZ='/boot/config-$(uname -r)命令得之。

#grep 'CONFIG_HZ=' /boot/config-$(uname -r)

CONFIG_HZ=250

如圖3-20所示，當前Memory中有「0」「1」「2」「3」「4」5個請求等待CPU處理。在當前時間段內CPU處理第「2」號請求，過了1/250s（假設CPU節拍率為250），處理第「3」號請求，然後依次循環處理「4」「0」「1」…號請求。

圖3-20 CPU節拍率