Linux 性能優(yōu)化總結(jié)！1

性能優(yōu)化

性能指標(biāo)

高并發(fā)和響應(yīng)快對應(yīng)著性能優(yōu)化的兩個(gè)核心指標(biāo)：吞吐和延時(shí)

• 應(yīng)用負(fù)載角度：直接影響了產(chǎn)品終端的用戶體驗(yàn)
• 系統(tǒng)資源角度：資源使用率、飽和度等

性能問題的本質(zhì)就是系統(tǒng)資源已經(jīng)到達(dá)瓶頸，但請求的處理還不夠快，無法支撐更多的請求。性能分析實(shí)際上就是找出應(yīng)用或系統(tǒng)的瓶頸，設(shè)法去避免或緩解它們。

• 選擇指標(biāo)評估應(yīng)用程序和系統(tǒng)性能
• 為應(yīng)用程序和系統(tǒng)設(shè)置性能目標(biāo)
• 進(jìn)行性能基準(zhǔn)測試
• 性能分析定位瓶頸
• 性能監(jiān)控和告警

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

到底應(yīng)該怎么理解”平均負(fù)載”

平均負(fù)載 ：單位時(shí)間內(nèi)，系統(tǒng)處于可運(yùn)行狀態(tài)和不可中斷狀態(tài)的平均進(jìn)程數(shù)，也就是平均活躍進(jìn)程數(shù)。它和我們傳統(tǒng)意義上理解的CPU使用率并沒有直接關(guān)系。

其中不可中斷進(jìn)程是正處于內(nèi)核態(tài)關(guān)鍵流程中的進(jìn)程（如常見的等待設(shè)備的I/O響應(yīng)）。不可中斷狀態(tài)實(shí)際上是系統(tǒng)對進(jìn)程和硬件設(shè)備的一種保護(hù)機(jī)制。

平均負(fù)載多少時(shí)合理

實(shí)際生產(chǎn)環(huán)境中將系統(tǒng)的平均負(fù)載監(jiān)控起來，根據(jù)歷史數(shù)據(jù)判斷負(fù)載的變化趨勢。當(dāng)負(fù)載存在明顯升高趨勢時(shí)，及時(shí)進(jìn)行分析和調(diào)查。當(dāng)然也可以當(dāng)設(shè)置閾值（如當(dāng)平均負(fù)載高于CPU數(shù)量的70%時(shí)）

現(xiàn)實(shí)工作中我們會經(jīng)?；煜骄?fù)載和CPU使用率的概念，其實(shí)兩者并不完全對等：

• CPU 密集型進(jìn)程，大量 CPU 使用會導(dǎo)致平均負(fù)載升高，此時(shí)兩者一致
• I/O 密集型進(jìn)程，等待 I/O 也會導(dǎo)致平均負(fù)載升高，此時(shí) CPU 使用率并不一定高
• 大量等待 CPU 的進(jìn)程調(diào)度會導(dǎo)致平均負(fù)載升高，此時(shí) CPU 使用率也會比較高

平均負(fù)載高時(shí)可能是 CPU 密集型進(jìn)程導(dǎo)致，也可能是 I/O 繁忙導(dǎo)致。具體分析時(shí)可以結(jié)合 mpstat/pidstat 工具輔助分析負(fù)載來源。

CPU

CPU上下文切換(上)

CPU 上下文切換，就是把前一個(gè)任務(wù)的 CPU 上下文（CPU 寄存器和 PC）保存起來，然后加載新任務(wù)的上下文到這些寄存器和程序計(jì)數(shù)器，最后再跳轉(zhuǎn)到程序計(jì)數(shù)器所指的位置，運(yùn)行新任務(wù)。其中，保存下來的上下文會存儲在系統(tǒng)內(nèi)核中，待任務(wù)重新調(diào)度執(zhí)行時(shí)再加載，保證原來的任務(wù)狀態(tài)不受影響。

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

• 進(jìn)程上下文切換
• 線程上下文切換
• 中斷上下文切換

進(jìn)程上下文切換

Linux 進(jìn)程按照等級權(quán)限將進(jìn)程的運(yùn)行空間分為內(nèi)核空間和用戶空間。從用戶態(tài)向內(nèi)核態(tài)轉(zhuǎn)變時(shí)需要通過系統(tǒng)調(diào)用來完成。

一次系統(tǒng)調(diào)用過程其實(shí)進(jìn)行了兩次 CPU 上下文切換：

• CPU 寄存器中用戶態(tài)的指令位置先保存起來，CPU 寄存器更新為內(nèi)核態(tài)指令的位置，跳轉(zhuǎn)到內(nèi)核態(tài)運(yùn)行內(nèi)核任務(wù)；
• 系統(tǒng)調(diào)用結(jié)束后，CPU 寄存器恢復(fù)原來保存的用戶態(tài)數(shù)據(jù)，再切換到用戶空間繼續(xù)運(yùn)行。

系統(tǒng)調(diào)用過程中并不會涉及虛擬內(nèi)存等進(jìn)程用戶態(tài)資源，也不會切換進(jìn)程。和傳統(tǒng)意義上的進(jìn)程上下文切換不同。因此系統(tǒng)調(diào)用通常稱為特權(quán)模式切換。

進(jìn)程是由內(nèi)核管理和調(diào)度的，進(jìn)程上下文切換只能發(fā)生在內(nèi)核態(tài)。因此相比系統(tǒng)調(diào)用來說，在保存當(dāng)前進(jìn)程的內(nèi)核狀態(tài)和CPU寄存器之前，需要先把該進(jìn)程的虛擬內(nèi)存，棧保存下來。再加載新進(jìn)程的內(nèi)核態(tài)后，還要刷新進(jìn)程的虛擬內(nèi)存和用戶棧。

進(jìn)程只有在調(diào)度到CPU上運(yùn)行時(shí)才需要切換上下文，有以下幾種場景：CPU時(shí)間片輪流分配，系統(tǒng)資源不足導(dǎo)致進(jìn)程掛起，進(jìn)程通過sleep函數(shù)主動掛起，高優(yōu)先級進(jìn)程搶占時(shí)間片，硬件中斷時(shí)CPU上的進(jìn)程被掛起轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務(wù)。

線程上下文切換

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

• 前后線程同屬于一個(gè)進(jìn)程，切換時(shí)虛擬內(nèi)存資源不變，只需要切換線程的私有數(shù)據(jù)，寄存器等；
• 前后線程屬于不同進(jìn)程，與進(jìn)程上下文切換相同。

同進(jìn)程的線程切換消耗資源較少，這也是多線程的優(yōu)勢。

中斷上下文切換

中斷上下文切換并不涉及到進(jìn)程的用戶態(tài)，因此中斷上下文只包括內(nèi)核態(tài)中斷服務(wù)程序執(zhí)行所必須的狀態(tài)（CPU寄存器，內(nèi)核堆棧，硬件中斷參數(shù)等）。

中斷處理優(yōu)先級比進(jìn)程高，所以中斷上下文切換和進(jìn)程上下文切換不會同時(shí)發(fā)生

CPU上下文切換(下)

通過 vmstat 可以查看系統(tǒng)總體的上下文切換情況

vmstat 5         #每隔5s輸出一組數(shù)據(jù)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） 每秒上下文切換次數(shù)
• in （interrupt） 每秒中斷次數(shù)
• r （runnning or runnable）就緒隊(duì)列的長度，正在運(yùn)行和等待CPU的進(jìn)程數(shù)
• b （Blocked） 處于不可中斷睡眠狀態(tài)的進(jìn)程數(shù)

要查看每個(gè)進(jìn)程的詳細(xì)情況，需要使用pidstat來查看每個(gè)進(jìn)程上下文切換情況

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

• cswch 每秒自愿上下文切換次數(shù)（進(jìn)程無法獲取所需資源導(dǎo)致的上下文切換）
• nvcswch 每秒非自愿上下文切換次數(shù)（時(shí)間片輪流等系統(tǒng)強(qiáng)制調(diào)度）

vmstat 1 1    #新終端觀察上下文切換情況此時(shí)發(fā)現(xiàn)cs數(shù)據(jù)明顯升高，同時(shí)觀察其他指標(biāo)：r列：遠(yuǎn)超系統(tǒng)CPU個(gè)數(shù)，說明存在大量CPU競爭us和sy列：sy列占比80%，說明CPU主要被內(nèi)核占用in列：中斷次數(shù)明顯上升，說明中斷處理也是潛在問題

說明運(yùn)行/等待CPU的進(jìn)程過多，導(dǎo)致大量的上下文切換，上下文切換導(dǎo)致系統(tǒng)的CPU占用率高

pidstat -w -u 1  #查看到底哪個(gè)進(jìn)程導(dǎo)致的問題

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

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

watch -d cat /proc/interrupts

發(fā)現(xiàn)次數(shù)變化速度最快的是重調(diào)度中斷（RES），該中斷用來喚醒空閑狀態(tài)的CPU來調(diào)度新的任務(wù)運(yùn)行。分析還是因?yàn)檫^多任務(wù)的調(diào)度問題，和上下文切換分析一致。

某個(gè)應(yīng)用的CPU使用率達(dá)到100%，怎么辦？

Linux作為多任務(wù)操作系統(tǒng)，將CPU時(shí)間劃分為很短的時(shí)間片，通過調(diào)度器輪流分配給各個(gè)任務(wù)使用。為了維護(hù)CPU時(shí)間，Linux通過事先定義的節(jié)拍率，觸發(fā)時(shí)間中斷，并使用全局變了jiffies記錄開機(jī)以來的節(jié)拍數(shù)。時(shí)間中斷發(fā)生一次該值+1.

CPU使用率，除了空閑時(shí)間以外的其他時(shí)間占總CPU時(shí)間的百分比?？梢酝ㄟ^/proc/stat中的數(shù)據(jù)來計(jì)算出CPU使用率。因?yàn)?proc/stat時(shí)開機(jī)以來的節(jié)拍數(shù)累加值，計(jì)算出來的是開機(jī)以來的平均CPU使用率，一般意義不大?？梢蚤g隔取一段時(shí)間的兩次值作差來計(jì)算該段時(shí)間內(nèi)的平均CPU使用率。性能分析工具給出的都是間隔一段時(shí)間的平均CPU使用率，要注意間隔時(shí)間的設(shè)置。

CPU使用率可以通過top 或 ps來查看。分析進(jìn)程的CPU問題可以通過perf，它以性能事件采樣為基礎(chǔ)，不僅可以分析系統(tǒng)的各種事件和內(nèi)核性能，還可以用來分析指定應(yīng)用程序的性能問題。

perf top / perf record / perf report （-g 開啟調(diào)用關(guān)系的采樣）

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服務(wù)性能

發(fā)現(xiàn)此時(shí)每秒可承受請求給長少，此時(shí)將測試的請求數(shù)從100增加到10000。在另外一個(gè)終端運(yùn)行top查看每個(gè)CPU的使用率。發(fā)現(xiàn)系統(tǒng)中幾個(gè)php-fpm進(jìn)程導(dǎo)致CPU使用率驟升。

接著用perf來分析具體是php-fpm中哪個(gè)函數(shù)導(dǎo)致該問題。

perf top -g -p XXXX #對某一個(gè)php-fpm進(jìn)程進(jìn)行分析

發(fā)現(xiàn)其中 sqrt 和 add_function 占用 CPU 過多， 此時(shí)查看源碼找到原來是sqrt中在發(fā)布前沒有刪除測試代碼段，存在一個(gè)百萬次的循環(huán)導(dǎo)致。將該無用代碼刪除后發(fā)現(xiàn)nginx負(fù)載能力明顯提升

系統(tǒng)的CPU使用率很高，為什么找不到高CPU的應(yīng)用？

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/ #并發(fā)100個(gè)請求測試

實(shí)驗(yàn)結(jié)果中每秒請求數(shù)依舊不高，我們將并發(fā)請求數(shù)降為5后，nginx負(fù)載能力依舊很低。

此時(shí)用top和pidstat發(fā)現(xiàn)系統(tǒng)CPU使用率過高，但是并沒有發(fā)現(xiàn)CPU使用率高的進(jìn)程。

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

下一步就利用pidstat分析這幾個(gè)stress進(jìn)程，發(fā)現(xiàn)沒有任何輸出。用ps aux交叉驗(yàn)證發(fā)現(xiàn)依舊不存在該進(jìn)程。說明不是工具的問題。再top查看發(fā)現(xiàn)stress進(jìn)程的進(jìn)程號變化了，此時(shí)有可能時(shí)以下兩種原因?qū)е拢?/p>

• 進(jìn)程不停的崩潰重啟（如段錯(cuò)誤/配置錯(cuò)誤等），此時(shí)進(jìn)程退出后可能又被監(jiān)控系統(tǒng)重啟；
• 短時(shí)進(jìn)程導(dǎo)致，即其他應(yīng)用內(nèi)部通過 exec 調(diào)用的外面命令，這些命令一般只運(yùn)行很短時(shí)間就結(jié)束，很難用top這種間隔較長的工具來發(fā)現(xiàn)

可以通過pstree來查找 stress 的父進(jìn)程，找出調(diào)用關(guān)系。

pstree | grep stress

發(fā)現(xiàn)是php-fpm調(diào)用的該子進(jìn)程，此時(shí)去查看源碼可以看出每個(gè)請求都會調(diào)用一個(gè)stress命令來模擬I/O壓力。之前top顯示的結(jié)果是CPU使用率升高，是否真的是由該stress命令導(dǎo)致的，還需要繼續(xù)分析。代碼中給每個(gè)請求加了verbose=1的參數(shù)后可以查看stress命令的輸出，在中斷測試該命令結(jié)果顯示stress命令運(yùn)行時(shí)存在因權(quán)限問題導(dǎo)致的文件創(chuàng)建失敗的bug。

此時(shí)依舊只是猜測，下一步繼續(xù)通過perf工具來分析。性能報(bào)告顯示確實(shí)時(shí)stress占用了大量的CPU，通過修復(fù)權(quán)限問題來優(yōu)化解決即可。

系統(tǒng)中出現(xiàn)大量不可中斷進(jìn)程和僵尸進(jìn)程怎么辦？

進(jìn)程狀態(tài)

R Running/Runnable，表示進(jìn)程在CPU的就緒隊(duì)列中，正在運(yùn)行或者等待運(yùn)行；

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

Z Zombie，僵尸進(jìn)程，表示進(jìn)程實(shí)際上已經(jīng)結(jié)束，但是父進(jìn)程還沒有回收它的資源；

S Interruptible Sleep，可中斷睡眠狀態(tài)，表示進(jìn)程因?yàn)榈却硞€(gè)事件而被系統(tǒng)掛起，當(dāng)?shù)却录l(fā)生則會被喚醒并進(jìn)入R狀態(tài)；

I Idle，空閑狀態(tài)，用在不可中斷睡眠的內(nèi)核線程上。該狀態(tài)不會導(dǎo)致平均負(fù)載升高；

T Stop/Traced，表示進(jìn)程處于暫?；蚋櫊顟B(tài)（SIGSTOP/SIGCONT， GDB調(diào)試）；

X Dead，進(jìn)程已經(jīng)消亡，不會在top/ps中看到。

對于不可中斷狀態(tài)，一般都是在很短時(shí)間內(nèi)結(jié)束，可忽略。但是如果系統(tǒng)或硬件發(fā)生故障，進(jìn)程可能會保持不可中斷狀態(tài)很久，甚至系統(tǒng)中出現(xiàn)大量不可中斷狀態(tài)，此時(shí)需注意是否出現(xiàn)了I/O性能問題。

僵尸進(jìn)程一般多進(jìn)程應(yīng)用容易遇到，父進(jìn)程來不及處理子進(jìn)程狀態(tài)時(shí)子進(jìn)程就提前退出，此時(shí)子進(jìn)程就變成了僵尸進(jìn)程。大量的僵尸進(jìn)程會用盡PID進(jìn)程號，導(dǎo)致新進(jìn)程無法建立。

磁盤O_DIRECT問題

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

可以看到此時(shí)有多個(gè)app進(jìn)程運(yùn)行，狀態(tài)分別時(shí)Ss+和D+。其中后面s表示進(jìn)程是一個(gè)會話的領(lǐng)導(dǎo)進(jìn)程，+號表示前臺進(jìn)程組。

其中進(jìn)程組表示一組相互關(guān)聯(lián)的進(jìn)程，子進(jìn)程是父進(jìn)程所在組的組員。會話指共享同一個(gè)控制終端的一個(gè)或多個(gè)進(jìn)程組。

用top查看系統(tǒng)資源發(fā)現(xiàn)：1）平均負(fù)載在逐漸增加，且1分鐘內(nèi)平均負(fù)載達(dá)到了CPU個(gè)數(shù)，說明系統(tǒng)可能已經(jīng)有了性能瓶頸；2）僵尸進(jìn)程比較多且在不停增加；3）us和sys CPU使用率都不高，iowait卻比較高；4）每個(gè)進(jìn)程CPU使用率也不高，但有兩個(gè)進(jìn)程處于D狀態(tài)，可能在等待IO。

分析目前數(shù)據(jù)可知：iowait過高導(dǎo)致系統(tǒng)平均負(fù)載升高，僵尸進(jìn)程不斷增長說明有程序沒能正確清理子進(jìn)程資源。

用dstat來分析，因?yàn)樗梢酝瑫r(shí)查看CPU和I/O兩種資源的使用情況，便于對比分析。

dstat 1 10    #間隔1秒輸出10組數(shù)據(jù)

可以看到當(dāng)wai（iowait）升高時(shí)磁盤請求read都會很大，說明iowait的升高和磁盤的讀請求有關(guān)。接下來分析到底時(shí)哪個(gè)進(jìn)程在讀磁盤。

之前 Top 查看的處于 D 狀態(tài)的進(jìn)程號，用 pidstat -d -p XXX 展示進(jìn)程的 I/O 統(tǒng)計(jì)數(shù)據(jù)。發(fā)現(xiàn)處于 D 狀態(tài)的進(jìn)程都沒有任何讀寫操作。在用 pidstat -d 查看所有進(jìn)程的 I/O統(tǒng)計(jì)數(shù)據(jù)，看到 app 進(jìn)程在進(jìn)行磁盤讀操作，每秒讀取 32MB 的數(shù)據(jù)。進(jìn)程訪問磁盤必須使用系統(tǒng)調(diào)用處于內(nèi)核態(tài)，接下來重點(diǎn)就是找到app進(jìn)程的系統(tǒng)調(diào)用。

sudo strace -p XXX #對app進(jìn)程調(diào)用進(jìn)行跟蹤

報(bào)錯(cuò)沒有權(quán)限，因?yàn)橐呀?jīng)時(shí) root 權(quán)限了。所以遇到這種情況，首先要檢查進(jìn)程狀態(tài)是否正常。ps 命令查找該進(jìn)程已經(jīng)處于Z狀態(tài)，即僵尸進(jìn)程。

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

看到 app 確實(shí)在通過系統(tǒng)調(diào)用 sys_read() 讀取數(shù)據(jù)，并且從 new_sync_read和 blkdev_direct_IO看出進(jìn)程時(shí)進(jìn)行直接讀操作，請求直接從磁盤讀，沒有通過緩存導(dǎo)致iowait升高。

通過層層分析后，root cause 是 app 內(nèi)部進(jìn)行了磁盤的直接I/O。然后定位到具體代碼位置進(jìn)行優(yōu)化即可。

僵尸進(jìn)程

上述優(yōu)化后 iowait 顯著下降，但是僵尸進(jìn)程數(shù)量仍舊在增加。首先要定位僵尸進(jìn)程的父進(jìn)程，通過pstree -aps XXX，打印出該僵尸進(jìn)程的調(diào)用樹，發(fā)現(xiàn)父進(jìn)程就是app進(jìn)程。

查看app代碼，看看子進(jìn)程結(jié)束的處理是否正確（是否調(diào)用wait()/waitpid()，有沒有注冊SIGCHILD信號的處理函數(shù)等）。

碰到iowait升高時(shí)，先用dstat pidstat等工具確認(rèn)是否存在磁盤I/O問題，再找是哪些進(jìn)程導(dǎo)致I/O，不能用strace直接分析進(jìn)程調(diào)用時(shí)可以通過perf工具分析。

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

CPU性能指標(biāo)

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

性能工具

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

根據(jù)不同的性能指標(biāo)來找合適的工具：

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

CPU優(yōu)化

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

  • QPS（TPS）

  • 并發(fā)數(shù)

  • 響應(yīng)時(shí)間

  • QPS（TPS）=并發(fā)數(shù)/平均相應(yīng)時(shí)間

  • 用戶請求服務(wù)器

  • 服務(wù)器內(nèi)部處理

  • 服務(wù)器返回給客戶

    QPS 類似 TPS，但是對于一個(gè)頁面的訪問形成一個(gè) TPS，但是一次頁面請求可能包含多次對服務(wù)器的請求，可能計(jì)入多次 QPS

  • QPS（Queries Per Second）每秒查詢率，一臺服務(wù)器每秒能夠響應(yīng)的查詢次數(shù).

  • TPS（Transactions Per Second）每秒事務(wù)數(shù)，軟件測試的結(jié)果.

• 系統(tǒng)吞吐量，包括幾個(gè)重要參數(shù)：