做性能測試的必備知識系列，可以看下面鏈接的文章哦
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：參考這篇文章，https://www.cnblogs.com/poloyy/p/13325507.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 性能
- 如果系統的上下文切換次數比較穩定，那么數百到一萬以內，都是正常的
- 但當上下文切換次數超過一萬次，或者切換次數出現數量級的增長時，就很可能已經出現了性能問題
深入分析
根據上下文切換的類型，具體分析
- 自願上下文切換多了，說明進程都在等待資源，有可能發生了 I/O 等其他問題
- 非自願上下文切換多了，說明進程都在被強制調度，也就是都在爭搶 CPU，說明 CPU 的確成了瓶頸
- 中斷次數變多了，說明 CPU 被中斷處理程序占用，還需要通過 /pro/interrupts 文件來分析具體的中斷類型
全文總結-如何查看分析上下文切換
- 通過 vmstat 確認系統的當前的上下文切換（cs）、中斷次數（in）、就緒隊列（r）、CPU 使用率（us、sy）
- 若上下文切換次數和 CPU 使用率過高，通過 pidstat 查看是哪個進程或線程的切換次數過高，CPU 使用率過高
- 然后確認是自願上下文切換還是非自願上下文切換，從而深入分析是否存在其他系統瓶頸問題
- 若中斷次數過高，通過 /proc/interrupts 分析是哪種中斷類型