LinuxCPU上下文切換的故障排查

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

檢查 CPU 的上下文切換

我們知道，過多的上下文切換會消耗 CPU 的時間來保存和恢復寄存器、程序計數器、內核棧和虛擬內存等數據，從而導致系統性能顯著下降。

既然上下文切換對系統性能的影響如此之大，那么我們如何檢查它呢？好了，你可以使用 vmstat 工具來查詢你系統的上下文切換。

vmstat

vmstat 是一種常用的系統性能分析工具。主要用于分析內存使用情況，也常用于分析 CPU 上下文切換和中斷的次數。

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

讓我們看一下輸出：

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

• in（interrupt）：每秒的中斷數。

• r（running | runnable）：就緒隊列的長度，即正在運行和等待 CPU 的進程數。

• b（blocked）：處于不間斷睡眠狀態的進程數。

在上面的例子中，我們可以看到上下文切換次數為 33 次，系統中斷次數為 25 次，就緒隊列長度，不間斷狀態進程數均為 0。

pidstat

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

例如：

#?Output?interval?is?5
$?pidstat?-w?5
Linux?4.15.0?(ubuntu)??09/23/18??_x86_64_??(2?CPU)
08:18:26??????UID???????PID???cswch/s?nvcswch/s??Command
08:18:31????????0?????????1??????0.20??????0.00??systemd
08:18:31????????0?????????8??????5.40??????0.00??rcu_sched
...

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

• 自愿上下文切換：指進程無法獲得所需資源而導致的上下文切換。例如，當 I/O 和內存等系統資源不足時，就會發生自愿上下文切換。

• 非自愿上下文切換：指進程因時間片已過期而被系統強制重新調度時發生的上下文切換。例如，當大量進程競爭 CPU 時，很容易發生非自愿的上下文切換。

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

案例分析

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

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

在我們模擬負載之前，讓我們在一個終端中運行一下 vmstat：

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

現在讓我們運行 sysbench 來模擬多線程調度系統的瓶頸：

$?sysbench?--threads=10?--max-time=300?threads?run

現在，您應該會看到 vmstat 輸出了與上面不同的結果：

應該可以發現 cs 欄的上下文切換次數從之前的 35 次突增到 139 萬次。同時，注意觀察其他幾個指標：

• r：就緒隊列的長度已達到 8

• us 和 sy：us 和 sy 的 CPU 使用率加起來是 100%，系統 CPU 使用率是 84%，說明 CPU 主要被內核占用。

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

結合這些指標我們可以知道系統的就緒隊列太長了，也就是有太多的進程在運行等待 CPU，導致大量的上下文切換，而大量的上下文切換導致了系統 CPU 使用率的增長。

那么是什么過程導致了這些問題呢？

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

#?1?means?output?interval?is?1?second
#?-w:?output?process?switching?index，
#?-u:?output?CPU?usage?index
$?pidstat?-w?-u?1
08:06:33??????UID???????PID????%usr?%system??%guest???%wait????%CPU???CPU??Command
08:06:34????????0?????10488???30.00??100.00????0.00????0.00??100.00?????0??sysbench
08:06:34????????0?????26326????0.00????1.00????0.00????0.00????1.00?????0??kworker/u4:2
08:06:33??????UID???????PID???cswch/s?nvcswch/s??Command
08:06:34????????0?????????8?????11.00??????0.00??rcu_sched
08:06:34????????0????????16??????1.00??????0.00??ksoftirqd/1
08:06:34????????0???????471??????1.00??????0.00??hv_balloon
08:06:34????????0??????1230??????1.00??????0.00??iscsid
08:06:34????????0??????4089??????1.00??????0.00??kworker/1:5
08:06:34????????0??????4333??????1.00??????0.00??kworker/0:3
08:06:34????????0?????10499??????1.00????224.00??pidstat
08:06:34????????0?????26326????236.00??????0.00??kworker/u4:2
08:06:34?????1000?????26784????223.00??????0.00??sshd

從 pidstat 的輸出可以發現，CPU 使用率的增加確實是 sysbench 造成的，它的 CPU 使用率已經達到了 100%。但上下文切換來自其他進程，包括非自愿上下文切換頻率最高的 pidstat，以及自愿上下文切換頻率最高的內核線程 kworker 和 sshd。

注意：默認情況下 pidstat 只顯示進程的上下文切換，如果要查看實際線程的上下文切換，請添加 -t 選項。

中斷

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

#?-d:?Highlight?the?change?area
$?watch?-d?cat?/proc/interrupts
???????????CPU0???????CPU1
...
RES:????2450431????5279697???Rescheduling?interrupts
...

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

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

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

結論

此時，你應該可以根據上下文切換的類型做一些具體的分析了。

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

• 非自愿上下文切換較多，說明進程正在被強制調度，也就是都在爭搶 CPU，說明 CPU 確實產生了瓶頸。

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