做效能測試的必備知識系列，可以看下面連結的文章哦
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 分析是哪種中斷型別