性能測試必備知識（6）- 如何查看「CPU 上下文切換」

作性能測試的必備知識系列，能夠看下面連接的文章哦

https://www.cnblogs.com/poloyy/category/1806772.html

 

課前準備，安裝 sysbench

下載 sysbench

git clone https://github.com/akopytov/sysbench.git

 

安裝依賴

yum install autoconf automake libtool -y

 

編譯安裝

cd sysbench/
./autogen.sh
./configure --without-mysql
make && make install

 

百度雲連接

連接：https://pan.baidu.com/s/1a9qR9GNzEbj1rkDp2wXfIw

提取碼：kone

下載壓縮包放到服務器，而後解壓便可

 

如何查看系統的上下文切換狀況

vmstat 

• 使用 vmstat 這個工具，來查詢系統的上下文切換狀況
• vmstat 是一個經常使用的系統性能分析工具，主要用來分析系統的內存使用狀況，也經常使用來分析 CPU 上下文切換和中斷的次數

 

瞭解 vmstat 輸出的參數含義

每隔 2s 輸出一次結果

vmstat 2

這裏咱們只瞭解必備參數，後面有單獨一篇文章展開來說解 vmstat 命令

參數分析

• cs（context switch）：每秒上下文切換的次數
• in（interrupt）：每秒中斷的次數
• r（Running or Runnable）：就緒隊列的長度，也就是正在運行和等待 CPU 的進程數
• b（Blocked）：處於不可中斷睡眠狀態的進程數

vmstat 只給出了系統整體的上下文切換狀況，如何查看每一個進程詳細狀況？答案是經過 pidstat

 

經過 pidstat 查看進程上下文切換的狀況

加上 -w 選項，每 3s 輸出一次結果，共輸出 3 次

pidstat -w 3 3

結果分析

• cswch：每秒自願上下文切換
• nvcswch：每秒非自願上下文切換的次數

 

自願上下文切換

• 進程沒法獲取所需自願，致使的上下文切換
• 栗子：I/O、內存等系統資源不足時，就會發生

 

非自願上下文切換

• 非自願上下文切換，則是指進程因爲時間片已到等緣由，被系統強制調度，進而發生的上下文切換
• 栗子：大量進程都在爭搶 CPU 時，就容易發生非自願上下文切換

 

經過栗子去看上下文切換

前期準備

• 安裝 sysbench：上面有提到了
• 安裝 sysstat：參考這篇文章，http://www.javashuo.com/article/p-blkqkpfg-kx.html
• 須要有一個虛擬機，我本身的虛擬機是 4核的哈
• 等下會經過遠程鏈接工具來遠程虛擬機，而後須要三個終端均訪問個人虛擬機

 

sysbench 介紹

• 一個多線程的基準測試工具（前面講的 stress 是多進程）
• 通常用來評估不一樣系統參數下的數據庫負載狀況
• 在接下來的案例中，主要是當成一個異常進程來看，做用是模擬上下文切換過多的問題

 

空閒系統的上下文切換次數

輸入如下命令，每 1 秒輸出一次結果，輸出 5 次

vmstat 1 5

結果分析

• 如今的上下文切換次數 cs 是 200-300左右，而中斷次數 in 是 200 左右，r 和 b 都是 0。
• 由於這會兒並無運行其餘任務，因此它們就是空閒系統的上下文切換次數

 

第一個終端運行 sysbench

輸入如下命令，以 10 個線程運行 5 分鐘的基準測試，模擬多線程切換的問題

sysbench --threads=10 --time=300 threads run

 

第二個終端經過 vmstat 查看上下文切換

vmstat 1

結果分析

• cs 列：上下文切換次數從以前 200 驟然上升到了 160w+...
• r 列：就緒隊列的長度最大到 8了，大於咱們的 CPU 個數 4，因此會存在大量的 CPU 競爭
• us、sy 列：兩列的 CPU 使用率加起來上升到了 80-90，其中系統 CPU 使用率都是 60%+，說明 CPU 主要是被內核佔用了
• in 列：中斷次數已經達到 8w 了...說明中斷處理也是個潛在的問題

 

總結下

• 系統的就緒隊列過長，也就是正在運行和等待 CPU 的進程數過多，致使了大量的上下文切換，而上下文切換又致使了 CPU 使用率升高
• 一環扣一環的，先有因後有果，別搞亂了順序

 

提出疑問

究竟是什麼進程致使了這些問題呢？

 

第三個終端經過 pidstat 來看進程的上下文切換次數

輸入如下命令，-w 輸出進程切換指標，-u 輸出 CPU 使用狀況

pidstat -w -u 1

結果分析

• sysbench 進程 CPU 使用率很高，已經差很少佔用了 4 個 CPU 了
• 但上下文切換次數多主要是其餘進程，包括內核線程 kworker
• 貌似全部進程加起來的上下文切換次數也就幾百，遠不如 vmstat 看到的上百萬，咋肥事！

 

分析下爲何上下文切換次數會這麼少

• 首先，Linux 調度的基本單位是線程
• sysbench 是模擬線程的調度問題

 

查看 pidstat 命令的做用

man pidstat

 

有那麼一句英文，能夠看到，pidstat 默認顯示進程級別的指標數據

• 而後往下翻，能夠看到 -t 參數
• 它能夠顯示與選定任務關聯的線程的統計信息

 

第三個終端從新執行 pidstat 命令

pidstat -wt 1 10

結果分析

sysbench 的多個線程的上下文切換次數有很是多，終於找到罪魁禍首了

 

分析爲何中斷次數也頗高

前面也說到 in 值達到了 8w，那是什麼致使中斷次數如此之高呢，接下來瞧一瞧

 

首先

中斷處理，它只發生在內核態，而 pidstat 只是一個進程的性能分析工具，並不提供任何關於中斷的詳細信息

 

如何查看中斷髮生的類型

從  /proc/interrupts  這個只讀文件中讀取

 /proc  其實是 Linux 的一個虛擬文件系統，用於內核空間與用戶空間之間的通訊

 

繼續在第三個終端執行命令

watch -d cat /proc/interrupts

結果分析

• 觀察一段時間，能夠發現變化速度最快的是重調度中斷（RES），表示喚醒空閒狀態的 CPU 來調度新的任務運行
• 這是多處理器系統（SMP）中，調度器用來分散任務到不一樣 CPU 的機制，一般也被稱爲處理器間中斷（Inter-Processor Interrupts， IPI）

 

總結

中斷次數升高仍是由於多任務的調度問題，和前面線程上下文切換次數的分析結果是一致的

 

每秒上下文切換多少次纔算正常？

• 這個數值其實取決於系統自己的 CPU 性能
• 若是系統的上下文切換次數比較穩定，那麼數百到一萬之內，都是正常的
• 但當上下文切換次數超過一萬次，或者切換次數出現數量級的增加時，就極可能已經出現了性能問題

 

深刻分析

根據上下文切換的類型，具體分析

1. 自願上下文切換多了，說明進程都在等待資源，有可能發生了 I/O 等其餘問題
2. 非自願上下文切換多了，說明進程都在被強制調度，也就是都在爭搶 CPU，說明 CPU 的確成了瓶頸
3. 中斷次數變多了，說明 CPU 被中斷處理程序佔用，還須要經過 /pro/interrupts  文件來分析具體的中斷類型

 

全文總結-如何查看分析上下文切換

• 經過 vmstat 確認系統的當前的上下文切換（cs）、中斷次數（in）、就緒隊列（r）、CPU 使用率（us、sy）
• 若上下文切換次數和 CPU 使用率太高，經過 pidstat 查看是哪一個進程或線程的切換次數太高，CPU 使用率太高
• 而後確認是自願上下文切換仍是非自願上下文切換，從而深刻分析是否存在其餘系統瓶頸問題
• 若中斷次數太高，經過 /proc/interrupts 分析是哪一種中斷類型