如何分析Linux CPU上下文切換問題

在我的上一篇文章：《探討 Linux CPU 的上下文切換》中，我談到了 CPU 上下文切換的工作原理?？焖倩仡櫼幌?，CPU 上下文切換是保證 Linux 系統(tǒng)正常運(yùn)行的核心功能。可分為進(jìn)程上下文切換、線程上下文切換和中斷上下文切換。

在本文中，我將進(jìn)一步討論如何分析 CPU 上下文切換問題。

檢查 CPU 的上下文切換

我們知道，過多的上下文切換會消耗 CPU 的時間來保存和恢復(fù)寄存器、程序計數(shù)器、內(nèi)核棧和虛擬內(nèi)存等數(shù)據(jù)，從而導(dǎo)致系統(tǒng)性能顯著下降。

既然上下文切換對系統(tǒng)性能的影響如此之大，那么我們?nèi)绾螜z查它呢？好了，你可以使用 vmstat 工具來查詢你系統(tǒng)的上下文切換。

vmstat

vmstat 是一種常用的系統(tǒng)性能分析工具。主要用于分析內(nèi)存使用情況，也常用于分析 CPU 上下文切換和中斷的次數(shù)。

例如 vmstat 5（5 秒輸出間隔）：

讓我們看一下輸出：

• cs（context switch）：每秒上下文切換的次數(shù)。

• in（interrupt）：每秒的中斷數(shù)。

• r（running | runnable）：就緒隊列的長度，即正在運(yùn)行和等待 CPU 的進(jìn)程數(shù)。

• b（blocked）：處于不間斷睡眠狀態(tài)的進(jìn)程數(shù)。

在上面的例子中，我們可以看到上下文切換次數(shù)為 33 次，系統(tǒng)中斷次數(shù)為 25 次，就緒隊列長度，不間斷狀態(tài)進(jìn)程數(shù)均為 0。

pidstat

vmstat 工具只給出了系統(tǒng)的整體上下文切換的信息。要查看每個進(jìn)程的詳細(xì)信息，您需要使用 pidstat。添加 -w 選項，您可以看到每個進(jìn)程的上下文切換：

例如：

#Outputintervalis5
$pidstat-w5
Linux4.15.0(ubuntu)09/23/18_x86_64_(2CPU)
0826UIDPIDcswch/snvcswch/sCommand
0831010.200.00systemd
0831085.400.00rcu_sched
...

結(jié)果中有兩列需要我們注意：cswch 和 nvcswch。其中，cswch 表示每秒自愿上下文切換的次數(shù)，nvcswch 表示每秒非自愿上下文切換的次數(shù)。

• 自愿上下文切換：指進(jìn)程無法獲得所需資源而導(dǎo)致的上下文切換。例如，當(dāng) I/O 和內(nèi)存等系統(tǒng)資源不足時，就會發(fā)生自愿上下文切換。

• 非自愿上下文切換：指進(jìn)程因時間片已過期而被系統(tǒng)強(qiáng)制重新調(diào)度時發(fā)生的上下文切換。例如，當(dāng)大量進(jìn)程競爭 CPU 時，很容易發(fā)生非自愿的上下文切換。

您必須牢記這兩個概念，因為它們意味著不同的性能問題。

案例分析

既然您知道如何查看這些指標(biāo)，那么就會出現(xiàn)另一個問題，上下文切換頻率多久才是正常的呢？讓我們看一個示例案例。

我們將使用 sysbench (https://github.com/akopytov/sysbenc)，一個多線程的基準(zhǔn)測試工具通過生成負(fù)載來模擬上下文切換過多的問題。假設(shè)您已經(jīng)在 Linux 系統(tǒng)上安裝了 sysbench 和 sysstat。

在我們模擬負(fù)載之前，讓我們在一個終端中運(yùn)行一下 vmstat：

在這里可以看到當(dāng)前的上下文切換次數(shù) cs 是 35，中斷次數(shù) in 是 19，r 和 b 都是 0。由于我目前沒有其他任務(wù)在運(yùn)行，因此它們是空閑系統(tǒng)中的上下文切換數(shù)量。

現(xiàn)在讓我們運(yùn)行 sysbench 來模擬多線程調(diào)度系統(tǒng)的瓶頸：

$sysbench--threads=10--max-time=300threadsrun

現(xiàn)在，您應(yīng)該會看到 vmstat 輸出了與上面不同的結(jié)果：

應(yīng)該可以發(fā)現(xiàn) cs 欄的上下文切換次數(shù)從之前的 35 次突增到 139 萬次。同時，注意觀察其他幾個指標(biāo)：

• r：就緒隊列的長度已達(dá)到 8

• us 和 sy：us 和 sy 的 CPU 使用率加起來是 100%，系統(tǒng) CPU 使用率是 84%，說明 CPU 主要被內(nèi)核占用。

• in：中斷數(shù)也上升到了 10000，說明中斷處理也是一個潛在的問題。

結(jié)合這些指標(biāo)我們可以知道系統(tǒng)的就緒隊列太長了，也就是有太多的進(jìn)程在運(yùn)行等待 CPU，導(dǎo)致大量的上下文切換，而大量的上下文切換導(dǎo)致了系統(tǒng) CPU 使用率的增長。

那么是什么過程導(dǎo)致了這些問題呢？

我們繼續(xù)分析，同時在第三個終端使用 pidstat，看看 CPU 和進(jìn)程上下文切換的情況：

#1meansoutputintervalis1second
#-w:outputprocessswitchingindex，
#-u:outputCPUusageindex
$pidstat-w-u1
0833UIDPID%usr%system%guest%wait%CPUCPUCommand
083401048830.00100.000.000.00100.000sysbench
08340263260.001.000.000.001.000kworker/u4:2
0833UIDPIDcswch/snvcswch/sCommand
08340811.000.00rcu_sched
08340161.000.00ksoftirqd/1
083404711.000.00hv_balloon
0834012301.000.00iscsid
0834040891.000.00kworker/1:5
0834043331.000.00kworker/0:3
08340104991.00224.00pidstat
0834026326236.000.00kworker/u4:2
0834100026784223.000.00sshd

從 pidstat 的輸出可以發(fā)現(xiàn)，CPU 使用率的增加確實是 sysbench 造成的，它的 CPU 使用率已經(jīng)達(dá)到了 100%。但上下文切換來自其他進(jìn)程，包括非自愿上下文切換頻率最高的 pidstat，以及自愿上下文切換頻率最高的內(nèi)核線程 kworker 和 sshd。

注意：默認(rèn)情況下 pidstat 只顯示進(jìn)程的上下文切換，如果要查看實際線程的上下文切換，請?zhí)砑?-t 選項。

中斷

要找出中斷數(shù)量也很高的原因所在，您可以檢查 /proc/interrupts 文件。該文件會提供一個只讀的中斷使用情況。

#-d:Highlightthechangearea
$watch-dcat/proc/interrupts
CPU0CPU1
...
RES:24504315279697Reschedulinginterrupts
...

觀察一段時間后，可以發(fā)現(xiàn)變化最快的是重新調(diào)度中斷（RES, REScheduling interrupt）。這種中斷類型表明處于空閑狀態(tài)的 CPU 被喚醒以調(diào)度新的任務(wù)運(yùn)行。所以這里的中斷增加是因為太多的任務(wù)調(diào)度問題，這和前面上下文切換次數(shù)的分析結(jié)果是一致的

現(xiàn)在回到最初的問題，每秒多少次上下文切換是正常的？

這個值實際上取決于系統(tǒng)本身的 CPU 性能。在我看來，如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定的話，幾百到一萬應(yīng)該是正常的。但是，當(dāng)上下文切換次數(shù)超過 10000，或者切換次數(shù)快速增加時，很可能是出現(xiàn)了性能問題。

結(jié)論

此時，你應(yīng)該可以根據(jù)上下文切換的類型做一些具體的分析了。

• 自愿上下文切換較多，說明進(jìn)程在等待資源，可能會出現(xiàn) I/O 飽和等其他問題。

• 非自愿上下文切換較多，說明進(jìn)程正在被強(qiáng)制調(diào)度，也就是都在爭搶 CPU，說明 CPU 確實產(chǎn)生了瓶頸。

• 中斷次數(shù)增多，說明 CPU 被中斷處理程序占用，需要通過查看 /proc/interrupts 文件來分析具體的中斷類型。