性能優化

性能指標

高并發和響應快對應著性能優化的兩個核心指標：吞吐和延時

• 應用負載角度：直接影響了產品終端的用戶體驗
• 系統資源角度：資源使用率、飽和度等

性能問題的本質就是系統資源已經到達瓶頸，但請求的處理還不夠快，無法支撐更多的請求。性能分析實際上就是找出應用或系統的瓶頸，設法去避免或緩解它們。

• 選擇指標評估應用程序和系統性能
• 為應用程序和系統設置性能目標
• 進行性能基準測試
• 性能分析定位瓶頸
• 性能監控和告警

對于不同的性能問題要選取不同的性能分析工具。下面是常用的Linux Performance Tools以及對應分析的性能問題類型。

到底應該怎么理解”平均負載”

平均負載 ：單位時間內，系統處于可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數。它和我們傳統意義上理解的CPU使用率并沒有直接關系。

其中不可中斷進程是正處于內核態關鍵流程中的進程（如常見的等待設備的I/O響應）。不可中斷狀態實際上是系統對進程和硬件設備的一種保護機制。

平均負載多少時合理

實際生產環境中將系統的平均負載監控起來，根據歷史數據判斷負載的變化趨勢。當負載存在明顯升高趨勢時，及時進行分析和調查。當然也可以當設置閾值（如當平均負載高于CPU數量的70%時）

現實工作中我們會經常混淆平均負載和CPU使用率的概念，其實兩者并不完全對等：

• CPU 密集型進程，大量 CPU 使用會導致平均負載升高，此時兩者一致
• I/O 密集型進程，等待 I/O 也會導致平均負載升高，此時 CPU 使用率并不一定高
• 大量等待 CPU 的進程調度會導致平均負載升高，此時 CPU 使用率也會比較高

平均負載高時可能是 CPU 密集型進程導致，也可能是 I/O 繁忙導致。具體分析時可以結合 mpstat/pidstat 工具輔助分析負載來源。

CPU

CPU上下文切換(上)

CPU 上下文切換，就是把前一個任務的 CPU 上下文（CPU 寄存器和 PC）保存起來，然后加載新任務的上下文到這些寄存器和程序計數器，最后再跳轉到程序計數器所指的位置，運行新任務。其中，保存下來的上下文會存儲在系統內核中，待任務重新調度執行時再加載，保證原來的任務狀態不受影響。

按照任務類型，CPU 上下文切換分為：

• 進程上下文切換
• 線程上下文切換
• 中斷上下文切換

進程上下文切換

Linux 進程按照等級權限將進程的運行空間分為內核空間和用戶空間。從用戶態向內核態轉變時需要通過系統調用來完成。

一次系統調用過程其實進行了兩次 CPU 上下文切換：

• CPU 寄存器中用戶態的指令位置先保存起來，CPU 寄存器更新為內核態指令的位置，跳轉到內核態運行內核任務；
• 系統調用結束后，CPU 寄存器恢復原來保存的用戶態數據，再切換到用戶空間繼續運行。

系統調用過程中并不會涉及虛擬內存等進程用戶態資源，也不會切換進程。和傳統意義上的進程上下文切換不同。因此系統調用通常稱為特權模式切換。

進程是由內核管理和調度的，進程上下文切換只能發生在內核態。因此相比系統調用來說，在保存當前進程的內核狀態和CPU寄存器之前，需要先把該進程的虛擬內存，棧保存下來。再加載新進程的內核態后，還要刷新進程的虛擬內存和用戶棧。

進程只有在調度到CPU上運行時才需要切換上下文，有以下幾種場景：CPU時間片輪流分配，系統資源不足導致進程掛起，進程通過sleep函數主動掛起，高優先級進程搶占時間片，硬件中斷時CPU上的進程被掛起轉而執行內核中的中斷服務。

線程上下文切換

線程上下文切換分為兩種：

• 前后線程同屬于一個進程，切換時虛擬內存資源不變，只需要切換線程的私有數據，寄存器等；
• 前后線程屬于不同進程，與進程上下文切換相同。

同進程的線程切換消耗資源較少，這也是多線程的優勢。

中斷上下文切換

中斷上下文切換并不涉及到進程的用戶態，因此中斷上下文只包括內核態中斷服務程序執行所必須的狀態（CPU寄存器，內核堆棧，硬件中斷參數等）。

中斷處理優先級比進程高，所以中斷上下文切換和進程上下文切換不會同時發生

CPU上下文切換(下)

通過 vmstat 可以查看系統總體的上下文切換情況

vmstat 5         #每隔5s輸出一組數據procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 1  0      0 103388 145412 511056    0    0    18    60    1    1  2  1 96  0  0 0  0      0 103388 145412 511076    0    0     0     2  450 1176  1  1 99  0  0 0  0      0 103388 145412 511076    0    0     0     8  429 1135  1  1 98  0  0 0  0      0 103388 145412 511076    0    0     0     0  431 1132  1  1 98  0  0 0  0      0 103388 145412 511076    0    0     0    10  467 1195  1  1 98  0  0 1  0      0 103388 145412 511076    0    0     0     2  426 1139  1  0 99  0  0 4  0      0  95184 145412 511108    0    0     0    74  500 1228  4  1 94  0  0 0  0      0 103512 145416 511076    0    0     0   455  723 1573 12  3 83  2  0

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

要查看每個進程的詳細情況，需要使用pidstat來查看每個進程上下文切換情況

pidstat -w 514時51分16秒   UID       PID   cswch/s nvcswch/s  Command14時51分21秒     0         1      0.80      0.00  systemd14時51分21秒     0         6      1.40      0.00  ksoftirqd/014時51分21秒     0         9     32.67      0.00  rcu_sched14時51分21秒     0        11      0.40      0.00  watchdog/014時51分21秒     0        32      0.20      0.00  khugepaged14時51分21秒     0       271      0.20      0.00  jbd2/vda1-814時51分21秒     0      1332      0.20      0.00  argusagent14時51分21秒     0      5265     10.02      0.00  AliSecGuard14時51分21秒     0      7439      7.82      0.00  kworker/0:214時51分21秒     0      7906      0.20      0.00  pidstat14時51分21秒     0      8346      0.20      0.00  sshd14時51分21秒     0     20654      9.82      0.00  AliYunDun14時51分21秒     0     25766      0.20      0.00  kworker/u2:114時51分21秒     0     28603      1.00      0.00  python3

• cswch 每秒自愿上下文切換次數（進程無法獲取所需資源導致的上下文切換）
• nvcswch 每秒非自愿上下文切換次數（時間片輪流等系統強制調度）

vmstat 1 1    #新終端觀察上下文切換情況此時發現cs數據明顯升高，同時觀察其他指標：r列：遠超系統CPU個數，說明存在大量CPU競爭us和sy列：sy列占比80%，說明CPU主要被內核占用in列：中斷次數明顯上升，說明中斷處理也是潛在問題

說明運行/等待CPU的進程過多，導致大量的上下文切換，上下文切換導致系統的CPU占用率高

pidstat -w -u 1  #查看到底哪個進程導致的問題

從結果中看出是 sysbench 導致 CPU 使用率過高，但是 pidstat 輸出的上下文次數加起來也并不多。分析 sysbench 模擬的是線程的切換，因此需要在 pidstat 后加 -t 參數查看線程指標。

另外對于中斷次數過多，我們可以通過 /proc/interrupts 文件讀取

watch -d cat /proc/interrupts

發現次數變化速度最快的是重調度中斷（RES），該中斷用來喚醒空閑狀態的CPU來調度新的任務運行。分析還是因為過多任務的調度問題，和上下文切換分析一致。

某個應用的CPU使用率達到100%，怎么辦？

Linux作為多任務操作系統，將CPU時間劃分為很短的時間片，通過調度器輪流分配給各個任務使用。為了維護CPU時間，Linux通過事先定義的節拍率，觸發時間中斷，并使用全局變了jiffies記錄開機以來的節拍數。時間中斷發生一次該值+1.

CPU使用率，除了空閑時間以外的其他時間占總CPU時間的百分比。可以通過/proc/stat中的數據來計算出CPU使用率。因為/proc/stat時開機以來的節拍數累加值，計算出來的是開機以來的平均CPU使用率，一般意義不大。可以間隔取一段時間的兩次值作差來計算該段時間內的平均CPU使用率。性能分析工具給出的都是間隔一段時間的平均CPU使用率，要注意間隔時間的設置。

CPU使用率可以通過top 或 ps來查看。分析進程的CPU問題可以通過perf，它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。

perf top / perf record / perf report （-g 開啟調用關系的采樣）

sudo docker run --name nginx -p 10000:80 -itd feisky/nginxsudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #測試Nginx服務性能

發現此時每秒可承受請求給長少，此時將測試的請求數從100增加到10000。在另外一個終端運行top查看每個CPU的使用率。發現系統中幾個php-fpm進程導致CPU使用率驟升。

接著用perf來分析具體是php-fpm中哪個函數導致該問題。

perf top -g -p XXXX #對某一個php-fpm進程進行分析

發現其中 sqrt 和 add_function 占用 CPU 過多， 此時查看源碼找到原來是sqrt中在發布前沒有刪除測試代碼段，存在一個百萬次的循環導致。將該無用代碼刪除后發現nginx負載能力明顯提升

系統的CPU使用率很高，為什么找不到高CPU的應用？

sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:spsudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:spab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并發100個請求測試

實驗結果中每秒請求數依舊不高，我們將并發請求數降為5后，nginx負載能力依舊很低。

此時用top和pidstat發現系統CPU使用率過高，但是并沒有發現CPU使用率高的進程。

出現這種情況一般時我們分析時遺漏的什么信息，重新運行top命令并觀察一會。發現就緒隊列中處于Running狀態的進行過多，超過了我們的并發請求次數5. 再仔細查看進程運行數據，發現nginx和php-fpm都處于sleep狀態，真正處于運行的卻是幾個stress進程。

下一步就利用pidstat分析這幾個stress進程，發現沒有任何輸出。用ps aux交叉驗證發現依舊不存在該進程。說明不是工具的問題。再top查看發現stress進程的進程號變化了，此時有可能時以下兩種原因導致：

• 進程不停的崩潰重啟（如段錯誤/配置錯誤等），此時進程退出后可能又被監控系統重啟；
• 短時進程導致，即其他應用內部通過 exec 調用的外面命令，這些命令一般只運行很短時間就結束，很難用top這種間隔較長的工具來發現

可以通過pstree來查找 stress 的父進程，找出調用關系。

pstree | grep stress

發現是php-fpm調用的該子進程，此時去查看源碼可以看出每個請求都會調用一個stress命令來模擬I/O壓力。之前top顯示的結果是CPU使用率升高，是否真的是由該stress命令導致的，還需要繼續分析。代碼中給每個請求加了verbose=1的參數后可以查看stress命令的輸出，在中斷測試該命令結果顯示stress命令運行時存在因權限問題導致的文件創建失敗的bug。

此時依舊只是猜測，下一步繼續通過perf工具來分析。性能報告顯示確實時stress占用了大量的CPU，通過修復權限問題來優化解決即可。

系統中出現大量不可中斷進程和僵尸進程怎么辦？

進程狀態

R Running/Runnable，表示進程在CPU的就緒隊列中，正在運行或者等待運行；

D Disk Sleep，不可中斷狀態睡眠，一般表示進程正在跟硬件交互，并且交互過程中不允許被其他進程中斷；

Z Zombie，僵尸進程，表示進程實際上已經結束，但是父進程還沒有回收它的資源；

S Interruptible Sleep，可中斷睡眠狀態，表示進程因為等待某個事件而被系統掛起，當等待事件發生則會被喚醒并進入R狀態；

I Idle，空閑狀態，用在不可中斷睡眠的內核線程上。該狀態不會導致平均負載升高；

T Stop/Traced，表示進程處于暫停或跟蹤狀態（SIGSTOP/SIGCONT， GDB調試）；

X Dead，進程已經消亡，不會在top/ps中看到。

對于不可中斷狀態，一般都是在很短時間內結束，可忽略。但是如果系統或硬件發生故障，進程可能會保持不可中斷狀態很久，甚至系統中出現大量不可中斷狀態，此時需注意是否出現了I/O性能問題。

僵尸進程一般多進程應用容易遇到，父進程來不及處理子進程狀態時子進程就提前退出，此時子進程就變成了僵尸進程。大量的僵尸進程會用盡PID進程號，導致新進程無法建立。

磁盤O_DIRECT問題

sudo docker run --privileged --name=app -itd feisky/app:iowaitps aux | grep '/app'

可以看到此時有多個app進程運行，狀態分別時Ss+和D+。其中后面s表示進程是一個會話的領導進程，+號表示前臺進程組。

其中進程組表示一組相互關聯的進程，子進程是父進程所在組的組員。會話指共享同一個控制終端的一個或多個進程組。

用top查看系統資源發現：1）平均負載在逐漸增加，且1分鐘內平均負載達到了CPU個數，說明系統可能已經有了性能瓶頸；2）僵尸進程比較多且在不停增加；3）us和sys CPU使用率都不高，iowait卻比較高；4）每個進程CPU使用率也不高，但有兩個進程處于D狀態，可能在等待IO。

分析目前數據可知：iowait過高導致系統平均負載升高，僵尸進程不斷增長說明有程序沒能正確清理子進程資源。

用dstat來分析，因為它可以同時查看CPU和I/O兩種資源的使用情況，便于對比分析。

dstat 1 10    #間隔1秒輸出10組數據

可以看到當wai（iowait）升高時磁盤請求read都會很大，說明iowait的升高和磁盤的讀請求有關。接下來分析到底時哪個進程在讀磁盤。

之前 Top 查看的處于 D 狀態的進程號，用 pidstat -d -p XXX 展示進程的 I/O 統計數據。發現處于 D 狀態的進程都沒有任何讀寫操作。在用 pidstat -d 查看所有進程的 I/O統計數據，看到 app 進程在進行磁盤讀操作，每秒讀取 32MB 的數據。進程訪問磁盤必須使用系統調用處于內核態，接下來重點就是找到app進程的系統調用。

sudo strace -p XXX #對app進程調用進行跟蹤

報錯沒有權限，因為已經時 root 權限了。所以遇到這種情況，首先要檢查進程狀態是否正常。ps 命令查找該進程已經處于Z狀態，即僵尸進程。

這種情況下top pidstat之類的工具無法給出更多的信息，此時像第5篇一樣，用 perf record -d和 perf report 進行分析，查看app進程調用棧。

看到 app 確實在通過系統調用 sys_read() 讀取數據，并且從 new_sync_read和 blkdev_direct_IO看出進程時進行直接讀操作，請求直接從磁盤讀，沒有通過緩存導致iowait升高。

通過層層分析后，root cause 是 app 內部進行了磁盤的直接I/O。然后定位到具體代碼位置進行優化即可。

僵尸進程

上述優化后 iowait 顯著下降，但是僵尸進程數量仍舊在增加。首先要定位僵尸進程的父進程，通過pstree -aps XXX，打印出該僵尸進程的調用樹，發現父進程就是app進程。

查看app代碼，看看子進程結束的處理是否正確（是否調用wait()/waitpid()，有沒有注冊SIGCHILD信號的處理函數等）。

碰到iowait升高時，先用dstat pidstat等工具確認是否存在磁盤I/O問題，再找是哪些進程導致I/O，不能用strace直接分析進程調用時可以通過perf工具分析。

對于僵尸問題，用pstree找到父進程，然后看源碼檢查子進程結束的處理邏輯即可。

CPU性能指標

• CPU使用率
  • 用戶CPU使用率, 包括用戶態(user)和低優先級用戶態(nice). 該指標過高說明應用程序比較繁忙.
  • 系統CPU使用率, CPU在內核態運行的時間百分比(不含中斷). 該指標高說明內核比較繁忙.
  • 等待I/O的CPU使用率, iowait, 該指標高說明系統與硬件設備I/O交互時間比較長.
  • 軟/硬中斷CPU使用率, 該指標高說明系統中發生大量中斷.
  • steal CPU / guest CPU, 表示虛擬機占用的CPU百分比.
• 平均負載
  • 理想情況下平均負載等于邏輯CPU個數,表示每個CPU都被充分利用. 若大于則說明系統負載較重.
• 進程上下文切換
  • 包括無法獲取資源的自愿切換和系統強制調度時的非自愿切換. 上下文切換本身是保證Linux正常運行的一項核心功能. 過多的切換則會將原本運行進程的CPU時間消耗在寄存器,內核占及虛擬內存等數據保存和恢復上
• CPU緩存命中率
  • CPU緩存的復用情況,命中率越高性能越好. 其中L1/L2常用在單核,L3則用在多核中

性能工具

• 平均負載案例
  • 先用uptime查看系統平均負載
  • 判斷負載在升高后再用mpstat和pidstat分別查看每個CPU和每個進程CPU使用情況.找出導致平均負載較高的進程.
• 上下文切換案例
  • 先用vmstat查看系統上下文切換和中斷次數
  • 再用pidstat觀察進程的自愿和非自愿上下文切換情況
  • 最后通過pidstat觀察線程的上下文切換情況
• 進程CPU使用率高案例
  • 先用top查看系統和進程的CPU使用情況,定位到進程
  • 再用perf top觀察進程調用鏈,定位到具體函數
• 系統CPU使用率高案例
  • 先用top查看系統和進程的CPU使用情況,top/pidstat都無法找到CPU使用率高的進程
  • 重新審視top輸出
  • 從CPU使用率不高,但是處于Running狀態的進程入手
  • perf record/report發現短時進程導致 (execsnoop工具)
• 不可中斷和僵尸進程案例
  • 先用top觀察iowait升高,發現大量不可中斷和僵尸進程
  • strace無法跟蹤進程系統調用
  • perf分析調用鏈發現根源來自磁盤直接I/O
• 軟中斷案例
  • top觀察系統軟中斷CPU使用率高
  • 查看/proc/softirqs找到變化速率較快的幾種軟中斷
  • sar命令發現是網絡小包問題
  • tcpdump找出網絡幀的類型和來源，確定SYN FLOOD攻擊導致

根據不同的性能指標來找合適的工具：

先運行幾個支持指標較多的工具，如 top/vmstat/pidstat，根據它們的輸出可以得出是哪種類型的性能問題。定位到進程后再用 strace/perf 分析調用情況進一步分析。如果是軟中斷導致用 /proc/softirqs

CPU優化

• 應用程序優化
  • 編譯器優化：編譯階段開啟優化選項，如gcc -O2
  • 算法優化
  • 異步處理：避免程序因為等待某個資源而一直阻塞，提升程序的并發處理能力。(將輪詢替換為事件通知)
  • 多線程代替多進程：減少上下文切換成本
  • 善用緩存：加快程序處理速度
• 系統優化
  • CPU綁定：將進程綁定要1個/多個CPU上，提高CPU緩存命中率，減少CPU調度帶來的上下文切換
  • CPU獨占：CPU親和性機制來分配進程
  • 優先級調整：使用nice適當降低非核心應用的優先級
  • 為進程設置資源顯示: cgroups設置使用上限，防止由某個應用自身問題耗盡系統資源
  • NUMA優化: CPU盡可能訪問本地內存
  • 中斷負載均衡: irpbalance，將中斷處理過程自動負載均衡到各個CPU上
• TPS、QPS、系統吞吐量的區別和理解

  • QPS（TPS）

  • 并發數

  • 響應時間

  • QPS（TPS）=并發數/平均相應時間

  • 用戶請求服務器

  • 服務器內部處理

  • 服務器返回給客戶

    QPS 類似 TPS，但是對于一個頁面的訪問形成一個 TPS，但是一次頁面請求可能包含多次對服務器的請求，可能計入多次 QPS

  • QPS（Queries Per Second）每秒查詢率，一臺服務器每秒能夠響應的查詢次數.

  • TPS（Transactions Per Second）每秒事務數，軟件測試的結果.

• 系統吞吐量，包括幾個重要參數：