Linux CPU 上下文切換的故障排查
在我的上一篇文章：《探討 Linux CPU 的上下文切換》中，我談到了 CPU 上下文切換的工作原理?？焖倩仡櫼幌?，CPU 上下文切換是保證 Linux 系統(tǒng)正常運行的核心功能?？煞譃?strong>進程上下文切換、線程上下文切換和中斷上下文切換。
在本文中，我將進一步討論如何分析 CPU 上下文切換問題。
檢查 CPU 的上下文切換
我們知道，過多的上下文切換會消耗 CPU 的時間來保存和恢復寄存器、程序計數(shù)器、內核棧和虛擬內存等數(shù)據(jù)，從而導致系統(tǒng)性能顯著下降。
既然上下文切換對系統(tǒng)性能的影響如此之大，那么我們如何檢查它呢？好了，你可以使用?vmstat?工具來查詢你系統(tǒng)的上下文切換。
vmstat
vmstat?是一種常用的系統(tǒng)性能分析工具。主要用于分析內存使用情況，也常用于分析 CPU 上下文切換和中斷的次數(shù)。
例如?vmstat 5（5 秒輸出間隔）：
讓我們看一下輸出：
-
cs（context switch）：每秒上下文切換的次數(shù)。 -
in（interrupt）：每秒的中斷數(shù)。 -
r（running | runnable）：就緒隊列的長度，即正在運行和等待 CPU 的進程數(shù)。 -
b（blocked）：處于不間斷睡眠狀態(tài)的進程數(shù)。
在上面的例子中，我們可以看到上下文切換次數(shù)為?33?次，系統(tǒng)中斷次數(shù)為?25?次，就緒隊列長度，不間斷狀態(tài)進程數(shù)均為?0。
pidstat
vmstat?工具只給出了系統(tǒng)的整體上下文切換的信息。要查看每個進程的詳細信息，您需要使用?pidstat。添加?-w?選項，您可以看到每個進程的上下文切換：
例如：
結果中有兩列需要我們注意：cswch?和?nvcswch。其中，cswch?表示每秒自愿上下文切換的次數(shù)，nvcswch?表示每秒非自愿上下文切換的次數(shù)。
-
自愿上下文切換：指進程無法獲得所需資源而導致的上下文切換。例如，當 I/O 和內存等系統(tǒng)資源不足時，就會發(fā)生自愿上下文切換。 -
非自愿上下文切換：指進程因時間片已過期而被系統(tǒng)強制重新調度時發(fā)生的上下文切換。例如，當大量進程競爭 CPU 時，很容易發(fā)生非自愿的上下文切換。
您必須牢記這兩個概念，因為它們意味著不同的性能問題。
案例分析
既然您知道如何查看這些指標，那么就會出現(xiàn)另一個問題，上下文切換頻率多久才是正常的呢？讓我們看一個示例案例。
我們將使用?sysbench?(https://github.com/akopytov/sysbenc)，一個多線程的基準測試工具通過生成負載來模擬上下文切換過多的問題。假設您已經(jīng)在 Linux 系統(tǒng)上安裝了?sysbench?和?sysstat。
在我們模擬負載之前，讓我們在一個終端中運行一下?vmstat：
在這里可以看到當前的上下文切換次數(shù)?cs?是?35，中斷次數(shù)?in?是?19，r?和?b?都是?0。由于我目前沒有其他任務在運行，因此它們是空閑系統(tǒng)中的上下文切換數(shù)量。
現(xiàn)在讓我們運行?sysbench?來模擬多線程調度系統(tǒng)的瓶頸：
現(xiàn)在，您應該會看到?vmstat?輸出了與上面不同的結果：
應該可以發(fā)現(xiàn)?cs?欄的上下文切換次數(shù)從之前的?35?次突增到?139?萬次。同時，注意觀察其他幾個指標：
-
r：就緒隊列的長度已達到?8 -
us?和?sy：us?和?sy?的 CPU 使用率加起來是?100%，系統(tǒng) CPU 使用率是?84%，說明 CPU 主要被內核占用。 -
in：中斷數(shù)也上升到了?10000，說明中斷處理也是一個潛在的問題。
結合這些指標我們可以知道系統(tǒng)的就緒隊列太長了，也就是有太多的進程在運行等待 CPU，導致大量的上下文切換，而大量的上下文切換導致了系統(tǒng) CPU 使用率的增長。
那么是什么過程導致了這些問題呢？
我們繼續(xù)分析，同時在第三個終端使用?pidstat，看看 CPU 和進程上下文切換的情況：
從?pidstat?的輸出可以發(fā)現(xiàn)，CPU 使用率的增加確實是?sysbench?造成的，它的 CPU 使用率已經(jīng)達到了?100%。但上下文切換來自其他進程，包括非自愿上下文切換頻率最高的?pidstat，以及自愿上下文切換頻率最高的內核線程?kworker?和?sshd。
注意：默認情況下?
pidstat?只顯示進程的上下文切換，如果要查看實際線程的上下文切換，請?zhí)砑?-t?選項。
中斷
要找出中斷數(shù)量也很高的原因所在，您可以檢查?/proc/interrupts?文件。該文件會提供一個只讀的中斷使用情況。
觀察一段時間后，可以發(fā)現(xiàn)變化最快的是重新調度中斷（RES, REScheduling interrupt）。這種中斷類型表明處于空閑狀態(tài)的 CPU 被喚醒以調度新的任務運行。所以這里的中斷增加是因為太多的任務調度問題，這和前面上下文切換次數(shù)的分析結果是一致的
現(xiàn)在回到最初的問題，每秒多少次上下文切換是正常的？
這個值實際上取決于系統(tǒng)本身的 CPU 性能。在我看來，如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定的話，幾百到一萬應該是正常的。但是，當上下文切換次數(shù)超過?10000，或者切換次數(shù)快速增加時，很可能是出現(xiàn)了性能問題。
結論
此時，你應該可以根據(jù)上下文切換的類型做一些具體的分析了。
-
自愿上下文切換較多，說明進程在等待資源，可能會出現(xiàn) I/O 飽和等其他問題。 -
非自愿上下文切換較多，說明進程正在被強制調度，也就是都在爭搶 CPU，說明 CPU 確實產生了瓶頸。 -
中斷次數(shù)增多，說明 CPU 被中斷處理程序占用，需要通過查看? /proc/interrupts?文件來分析具體的中斷類型。
鏈接：https://blog.devgenius.io/linux-cpu-context-switch-troubleshooting-bda45883e59e
（版權歸原作者所有，侵刪）