python linux 优化_Linux性能优化(一)
性能指標
性能優(yōu)化的兩個核心指標——"吞吐"和"延遲"，這是從應(yīng)用負載的視角來進行考察系統(tǒng)性能，直接影響了產(chǎn)品終端的用戶體驗。與之對應(yīng)的是從系統(tǒng)資源的視角出發(fā)的指標，比如資源使用率、飽和度等。
我們知道，隨著應(yīng)用負載的增加，系統(tǒng)資源的使用也會升高，甚至達到極限。而性能問題的本質(zhì)，就是系統(tǒng)資源已經(jīng)達到瓶頸，但請求的處理卻還不夠快，無法支撐更多的請求。
性能分析，其實就是找出應(yīng)用或系統(tǒng)的瓶頸，并設(shè)法去避免或者緩解他們，從而更高效地利用系統(tǒng)資源處理更多的請求。這包含了一系列的步驟，比如下面這六個步驟。
選擇指標評估應(yīng)用程序和系統(tǒng)的性能
為應(yīng)用程序和系統(tǒng)設(shè)置性能目標
進行性能基準測試
性能分析定位瓶頸
優(yōu)化系統(tǒng)和應(yīng)用程序
性能監(jiān)控和告警
這個圖是Linux性能分析最重要的參考資料之一，它告訴你，在Linux不同子系統(tǒng)出現(xiàn)性能問題后，應(yīng)該用什么樣的工具來觀測和分析。
比如，當遇到IO性能問題時，可以參考圖片下方的IO子系統(tǒng)，使用iostat、iotop、blktrace等工具分析磁盤IO的瓶頸。
理解平均負載
平均負載
平均負載是指單位時間內(nèi)，系統(tǒng)處于可運行狀態(tài)和不可中斷狀態(tài)的平均進程數(shù)，也就是平均活躍進程數(shù)，它和CPU使用率并沒有直接關(guān)系。
可運行狀態(tài)的進程，是指正在使用CPU或者正在等待CPU的進程，也就是ps命令查看進程狀態(tài)中的R狀態(tài)(Running或Runnable)。
不可中斷狀態(tài)的進程，是指正處于內(nèi)核態(tài)關(guān)鍵流程中的進程，并且這些流程是不可打斷的，比如最長間的是等待硬件設(shè)備的IO響應(yīng)，也就是ps命令查看進程狀態(tài)中的D狀態(tài)。例如，當一個進程向磁盤讀取數(shù)據(jù)時，為了保證數(shù)據(jù)的一致性，在得到磁盤回復(fù)前，它是不能被其他進程或者中斷打斷，這個時候的進程處于不可中斷狀態(tài)。如果此時的進程被打斷，就容易出現(xiàn)磁盤數(shù)據(jù)與進程數(shù)據(jù)不一致的問題。所以，不可中斷狀態(tài)實際上是系統(tǒng)對進程和硬件設(shè)備的一種保護機制。因此平均負載可以理解為平均活躍進程數(shù)。平均進程活躍數(shù)，直觀上的理解就是單位時間內(nèi)的活躍進程數(shù)，但實際上是活躍進程數(shù)的指數(shù)衰減平均值，可以直接理解為活躍進程數(shù)的平均值。
如果當平均負載為2時，就意味著
在只有2個CPU的系統(tǒng)上，意味著所有的CPU都剛好被完全占用。
在4個CPU的系統(tǒng)上，意味著CPU有50%的空閑。
在1個CPU的系統(tǒng)中，意味著有一半的進程競爭不到CPU
平均負載為多少時合理
平均負載最理想的情況是等于CPU個數(shù)，所以在評判平均負載時，首先要知道系統(tǒng)有幾個CPU，有了CPU個數(shù)，我們可以判斷出，當平均負載比CPU個數(shù)還大的時候，系統(tǒng)已經(jīng)出現(xiàn)了過載。
三個不同時間間隔的平均負載，其實給我們提供了，分析系統(tǒng)負載趨勢的數(shù)據(jù)來源，讓我們更能全面、更立體地理解目前的負載情況。
如果1分鐘、5分鐘、15分鐘的三個值基本相同，或者相差不大，那就說明系統(tǒng)負載很平穩(wěn)。
但如果1分鐘的值遠小于15分鐘的值，就說明系統(tǒng)最近1分鐘的負載在減少，而過去15分鐘內(nèi)卻有很大的負載
如果1分鐘的值遠大于15分鐘的值，就說明最近1分鐘的負載在增加，這種增加有可能只是臨時性的，也有可能還會持續(xù)增加下去，所以就需要持續(xù)觀察。一旦1分鐘的平均負載接近或者超過CPU的個數(shù)，就意味著系統(tǒng)正在發(fā)生過載的問題，這時就得分析調(diào)查是哪里導致的問題，并要想辦法優(yōu)化。
分析排查負載過高的問題需要把系統(tǒng)的平均負載監(jiān)控起來，然后根據(jù)更多的歷史數(shù)據(jù)，判斷負載的變化趨勢，當發(fā)生負載有明顯升高趨勢時，比如說負載翻倍了，再去做分析和調(diào)查
平均負載與CPU使用率
CPU密集型進程，使用大量CPU會導致平均負載升高
IO密集型進程，等待IO也會導致平均負載升高，單CPU使用率不一定很高。
大量等待CPU的進程調(diào)度也會導致平均負載升高，此時的CPU使用率也會比較高。
分析負載工具
CPU場景監(jiān)控
mpstat是一個常用的多核CPU性能分析工具，用來實時查看每個CPU的性能指標，以及所有CPU的平均指標
[root@localhost ~]# mpstat 2
Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_(4 CPU)
05:49:27 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:49:29 PM all 0.50 0.00 0.50 0.00 0.00 0.00 0.00 0.00 99.00
05:49:31 PM all 0.38 0.00 0.38 0.00 0.00 0.00 0.00 0.00 99.25
05:49:33 PM all 0.25 0.00 0.50 0.00 0.00 0.00 0.00 0.00 99.25
05:49:35 PM all 0.25 0.00 0.50 0.00 0.00 0.00 0.00 0.00 99.25
pidstat是一個常用的進程性能分析工具，用來實時查看進程的CPU、內(nèi)存、IO以及山下文切換等性能指標。
[root@localhost ~]# stress --cpu 1 --timeout 600
stress: info: [6168] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
[root@localhost ~]# uptime
17:59:36 up 405 days, 8:51, 2 users, load average: 0.99, 0.75, 0.35
[root@localhost ~]# mpstat -P ALL 2 3
Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_(4 CPU)
05:57:44 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:57:46 PM all 25.41 0.00 0.50 0.00 0.00 0.00 0.00 0.00 74.09
05:57:46 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
05:57:46 PM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:57:46 PM 2 1.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.99
05:57:46 PM 3 0.00 0.00 2.01 0.00 0.00 0.00 0.00 0.00 97.99
05:57:46 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
05:57:48 PM all 25.37 0.00 0.50 0.00 0.00 0.00 0.00 0.00 74.12
05:57:48 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
05:57:48 PM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:57:48 PM 2 1.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 98.50
05:57:48 PM 3 1.00 0.00 1.49 0.00 0.00 0.00 0.00 0.00 97.51
[root@localhost ~]# pidstat -u 5 1
Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_(4 CPU)
06:08:20 PM PID %usr %system %guest %CPU CPU Command
06:08:25 PM 3360 0.00 0.20 0.00 0.20 0 redis-server
06:08:25 PM 3593 0.20 0.20 0.00 0.40 3 bash
06:08:25 PM 3723 0.60 0.20 0.00 0.80 0 netdata
06:08:25 PM 3748 0.20 0.00 0.00 0.20 0 python
06:08:25 PM 7276 100.00 0.00 0.00 100.00 1 stress
06:08:25 PM 7289 0.00 0.20 0.00 0.20 3 pidstat
06:08:25 PM 25850 0.40 1.00 0.00 1.40 2 apps.plugin
Average: PID %usr %system %guest %CPU CPU Command
Average: 3360 0.00 0.20 0.00 0.20 - redis-server
Average: 3593 0.20 0.20 0.00 0.40 - bash
Average: 3723 0.60 0.20 0.00 0.80 - netdata
Average: 3748 0.20 0.00 0.00 0.20 - python
Average: 7276 100.00 0.00 0.00 100.00 - stress
Average: 7289 0.00 0.20 0.00 0.20 - pidstat
Average: 25850 0.40 1.00 0.00 1.40 - apps.plugin
首先利用stress模擬一個CPU使用率100%的情況，然后利用uptime觀察平均負載的變化情況，最后使用mpstat查看每個CPU使用率的情況；從uptime命令可以看到1分鐘內(nèi)的平均負載==1，而mpstat命令看到CPU1的使用率為100%，且都是在用戶態(tài)空間使用的CPU，說明導致負載升高是由于CPU使用率比較高引起的負載升高；最后使用pidstat監(jiān)測，發(fā)現(xiàn)是stress進程CPU使用為100%
IO密集型應(yīng)用
[root@localhost ~]# stress -i 1 --timeout 600stress:info: [7582] dispatching hogs: 0 cpu, 1 io, 0 vm, 0hdd
[root@localhost~]# uptime
18:13:11 up 405 days, 9:05, 2 users, load average: 0.80, 0.66, 0.46[root@localhost~]# uptime
18:13:16 up 405 days, 9:05, 2 users, load average: 0.82, 0.66, 0.47[root@localhost~]# uptime
18:13:24 up 405 days, 9:05, 2 users, load average: 0.84, 0.67, 0.47[root@localhost~]# uptime
18:13:30 up 405 days, 9:05, 2 users, load average: 0.86, 0.68, 0.47[root@localhost~]# uptime
18:13:39 up 405 days, 9:05, 2 users, load average: 0.88, 0.69, 0.48[root@localhost~]# uptime
18:13:47 up 405 days, 9:05, 2 users, load average: 0.90, 0.70, 0.48[root@localhost~]# uptime
18:14:05 up 405 days, 9:06, 2 users, load average: 0.92, 0.71, 0.49[root@localhost~]# uptime
18:14:22 up 405 days, 9:06, 2 users, load average: 0.94, 0.73, 0.50[root@localhost~]# uptime
18:14:47 up 405 days, 9:06, 2 users, load average: 0.96, 0.74, 0.51[root@localhost~]# uptime
18:15:28 up 405 days, 9:07, 2 users, load average: 0.98, 0.78, 0.53[root@localhost~]# mpstat -P ALL 5 1Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_ (4CPU)06:17:07 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle06:17:12 PM all 0.35 0.00 24.90 0.05 0.00 0.00 0.00 0.00 74.70
06:17:12 PM 0 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 99.60
06:17:12 PM 1 0.00 0.00 97.79 0.00 0.00 0.00 0.00 0.00 2.21
06:17:12 PM 2 0.40 0.00 1.20 0.00 0.00 0.00 0.00 0.00 98.40
06:17:12 PM 3 0.81 0.00 0.60 0.00 0.00 0.00 0.00 0.00 98.59Average: CPU%usr %nice %sys %iowait %irq %soft %steal %guest %idle
Average: all0.35 0.00 24.90 0.05 0.00 0.00 0.00 0.00 74.70Average:0 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 99.60Average:1 0.00 0.00 97.79 0.00 0.00 0.00 0.00 0.00 2.21Average:2 0.40 0.00 1.20 0.00 0.00 0.00 0.00 0.00 98.40Average:3 0.81 0.00 0.60 0.00 0.00 0.00 0.00 0.00 98.59Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_ (4CPU)
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda0.00 6.62 0.00 0.28 0.10 55.18 197.39 0.00 16.34 17.61 16.33 2.20 0.06sdb0.00 8.30 0.00 0.14 0.09 67.52 466.32 0.00 19.77 11.13 19.87 1.55 0.02dm-0 0.00 0.00 0.01 15.34 0.19 122.70 8.01 0.03 2.04 22.82 2.03 0.05 0.08dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 9.10 9.16 8.86 6.09 0.00
可以看到結(jié)合iostat分析發(fā)現(xiàn)導致負載升高的是IO導致系統(tǒng)負載升高
[root@localhost ~]# stress -c 8 --timeout 600stress:info: [8429] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd
利用stress -c 8 --timeout 600可以模擬更加復(fù)雜的場景
CPU上下文切換
Linux是一個多任務(wù)操作系統(tǒng)，它支持遠大于CPU數(shù)量的任務(wù)同時運行。當然，這些任務(wù)實際上并不是真的在同時運行，而是因為系統(tǒng)在很短的時間內(nèi)，將CPU輪流分配給它們，造成多任務(wù)同時運行的錯覺。每個任務(wù)運行前，CPU都需要知道任務(wù)從哪里加載，又從哪里開始運行，也就是說，需要系統(tǒng)事先幫它設(shè)置好CPU寄存器和程序計數(shù)器。CPU寄存器，是CPU內(nèi)置的容量小，但速度極快的內(nèi)存。程序計數(shù)器，則是用來存儲CPU正在執(zhí)行的指令位置，或者即將執(zhí)行的下一條指令位置。它們都是CPU在運行任務(wù)前，必須的依賴環(huán)境，因此也被叫做CPU上下文。
CPU上下文切換，就是先把前一個任務(wù)的CPU上下文保存起來，然后加載新任務(wù)的上下文到這些寄存器和程序計數(shù)器，最后再跳轉(zhuǎn)到程序計數(shù)器所指的新位置，運行新任務(wù)。而這些保存下來的上下文，會存儲在系統(tǒng)內(nèi)核中，并在任務(wù)重新調(diào)度執(zhí)行時再次加載進來。這樣就能保證任務(wù)原來的狀態(tài)不受影響，讓任務(wù)看起來還是連續(xù)執(zhí)行。
根據(jù)任務(wù)的不同，CPU的上下文切換就可以分為進程上下文切換、線程上下文切換以及中斷上下文切換。
進程上下文切換
Linux按照特權(quán)等級，把進程的運行空間分為內(nèi)核空間和用戶空間，分別對應(yīng)著下圖中，CPU特權(quán)等級的Ring0和Ring3。
內(nèi)核空間(Ring0)具有最高權(quán)限，可以直接訪問所有資源；
用戶空間(Ring3)只能訪問受限資源，不能直接訪問內(nèi)存等硬件設(shè)備，必須通過系統(tǒng)調(diào)用陷入到內(nèi)核中，才能訪問這些特權(quán)資源。
也就是說，進程既可以在用戶空間運行，又可以在內(nèi)核空間中運行。進程在用戶空間運行時，被稱為進程的用戶態(tài)，而陷入內(nèi)核空間的時候，被稱為進程的內(nèi)核態(tài)。
從用戶態(tài)到內(nèi)核態(tài)的轉(zhuǎn)變，需要通過系統(tǒng)調(diào)用來完成。比如，當我們查看文件內(nèi)容時，就需要多次系統(tǒng)調(diào)用來完成：首先調(diào)用open()打開文件，然后調(diào)用read()讀取文件內(nèi)容，并調(diào)用write()將內(nèi)容寫到標準輸出，最后再調(diào)用close()關(guān)閉文件。
CPU寄存器里原來用戶態(tài)的指令位置，需要先保存起來。接著，為了執(zhí)行內(nèi)核態(tài)代碼，CPU寄存器需要更新為內(nèi)核態(tài)指令的新位置，最后才是跳轉(zhuǎn)到內(nèi)核態(tài)運行內(nèi)核任務(wù)。
而系統(tǒng)調(diào)用結(jié)束后，CPU寄存器需要恢復(fù)原來保存的用戶態(tài)，然后在切換到用戶空間，繼續(xù)運行進程。所以，一次系統(tǒng)調(diào)用的過程，其實是發(fā)生了兩次CPU上下文切換。
不過，需要注意的是，系統(tǒng)調(diào)用過程中，并不會涉及到虛擬內(nèi)存等進程用戶的資源，也不會切換進程。這與我們通常所說的進程上下文切換是不一樣的：
進程上下文切換，是指從一個進程切換到另一個進程運行。
而系統(tǒng)調(diào)用過程中一直是同一個進程在運行。
所以，系統(tǒng)調(diào)用過程通常稱為特權(quán)模式切換，而不是上下文切換。但實際上，系統(tǒng)調(diào)用過程中，CPU的上下文切換還是無法避免的。
進程上下文切換跟系統(tǒng)調(diào)用的區(qū)別：
首先，需要知道，進程是由內(nèi)核來管理和調(diào)度的，進程的切換只能發(fā)生在內(nèi)核態(tài)。所以，進程的上下文不僅包括了虛擬內(nèi)存、棧、全局變量等用戶空間的資源，還包括了內(nèi)核堆棧、寄存器等內(nèi)核空間的狀態(tài)。
因此，進程上下文切換就比系統(tǒng)調(diào)用多了一步：在保存當前進程的內(nèi)核狀態(tài)和CPU寄存器之前，需要先把該進程的虛擬內(nèi)存、棧等保存下來；而加載了下一進程的內(nèi)核態(tài)后，還需要刷新進程的虛擬內(nèi)存和用戶棧。
如下圖所示，保存上下文和恢復(fù)上下文的過程并不是免費的，需要內(nèi)核在CPU上運行才能完成。
根據(jù)研究表明，每次上下文切換都需要幾十納秒到數(shù)微秒的CPU時間，這個時間還是相當可觀的，特別是在進程上下文切換次數(shù)較多的情況下，很容易導致CPU將大量時間耗費在寄存器、內(nèi)核棧以及虛擬內(nèi)存等資源的保存和恢復(fù)上，進而大大縮短了真正運行進程的時間。這也是導致平均負載上升的一個重要因素。
Linux通過TLB來管理虛擬內(nèi)存到物理內(nèi)存的映射關(guān)系。當虛擬內(nèi)存更新后，TLB也需要刷新，內(nèi)存的訪問也會隨之變慢。特別是在多處理系統(tǒng)上，緩存是被多個處理器共享的，刷新緩存不僅會影響當前處理器的進程，還會影響共享緩存的其他處理器的進程。
顯然，進程切換時才需要切換上下文，換句話說，只有在進程調(diào)度的時候，才需要切換上下文。Linux為每個CPU都維護了一個就緒隊列，將活躍進程(即正在運行和正在等待CPU的進程)按照優(yōu)先級和等待CPU的時間排序，然后選擇最需要CPU的進程，這也就是優(yōu)先級最高和等待CPU時間最長的進程來運行。
觸發(fā)進程調(diào)度的場景：
為了保證所有進程可以得到公平調(diào)度，CPU時間被劃分為一段段的時間片，這些時間片再被輪流分配給各個進程。這樣，當某個進程的時間片耗盡了，就會被系統(tǒng)掛起，切換到其它正在等待CPU的進程執(zhí)行。
進程在系統(tǒng)資源不足時，要等到資源滿足后才可以運行，這個時候進程也會被掛起，并由系統(tǒng)調(diào)度其它進程運行。
當進程通過睡眠函數(shù)sleep這樣的方法將自己主動掛起時，自然也會重新調(diào)度。
當有優(yōu)先級更高的進程運行時，為了保證高優(yōu)先級進程的運行，當前進程會被掛起，由高優(yōu)先級進程來運行。
當發(fā)生硬中斷時，CPU上的進程會被掛起，轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務(wù)程序。
線程上下文切換
線程與進程最大的區(qū)別在于，線程是調(diào)度的基本單位，而進程則是資源擁有的基本單位。所謂內(nèi)核中的任務(wù)調(diào)度，實際上的調(diào)度對象是線程；而進程只是給線程提供了虛擬內(nèi)存、全局變量等資源。所以，對于線程和進程可以這么理解：
當進程只有一個線程時，可以認為進程就等于線程。
當進程擁有多個線程時，這些線程會共享相同的虛擬內(nèi)存和全局變量等資源。這些資源在上下文切換時是不需要修改的。
線程也有自己的私有數(shù)據(jù)，比如棧和寄存器等，這些在上下文切換時也是需要保存的。
因此，線程的上下文切換其實就可以分為兩種情況：
第一種，前后兩個線程屬于不同進程。此時，資源不同享，所以切換過程就跟進程上下文切換是一樣的。
第二種，前后兩個線程屬于同一個進程。此時，虛擬內(nèi)存是共享的，所以在切換時，虛擬內(nèi)存這些資源就保持不動，只需要切換線程的私有數(shù)據(jù)、寄存器等不同享數(shù)據(jù)。
通過以上情況可以發(fā)現(xiàn)，雖然同為上下文切換，但同進程內(nèi)的線程切換，要比多進程間切換消耗更少的資源，而這，也正是多線程代替多進程的一個優(yōu)勢。
中斷上下文切換
切換進程CPU上下文，其實就是中斷上下文切換。為了快速響應(yīng)硬件的事件，中斷處理會打斷進程的正常調(diào)度和執(zhí)行，轉(zhuǎn)而調(diào)用中斷處理程序，響應(yīng)設(shè)備事件。而在打斷其他進程時，就需要將進程當前狀態(tài)保存下來，這樣在中斷結(jié)束后，進程仍然可以從原來的狀態(tài)恢復(fù)運行。
跟進程上下文不同，中斷上下文切換并不涉及到進程的用戶態(tài)。所以，即便中斷過程打斷了一個正處在用戶態(tài)的進程，也不需要保存和恢復(fù)這個進程的虛擬內(nèi)存、全局變量等用戶態(tài)資源。中斷上下文，其實只包括內(nèi)核態(tài)中斷服務(wù)程序執(zhí)行所必須的狀態(tài)，包括CPU寄存器、內(nèi)核堆棧、硬件中斷參數(shù)等。
對同一個CPU來說，中斷處理比進程擁有更高的優(yōu)先級，所以中斷上下文切換并不會與進程上下文切換同時發(fā)生。同樣道理，由于中斷會打斷正常進程的調(diào)度和執(zhí)行，所以大部分中斷處理程序都短小精悍，以便盡可能快的執(zhí)行結(jié)束。
另外，跟進程上下文切換一樣，中斷上下文切換也需要消耗CPU，切換次數(shù)過多也會消耗大量的CPU，甚至嚴重降低系統(tǒng)的整體性能。所以，當發(fā)現(xiàn)中斷次數(shù)過多時，就需要注意去排查它是否會給系統(tǒng)帶來嚴重的性能問題。
CPU上下文切換分析
查看系統(tǒng)上下文
利用vmstat工具來進行查看上下文切換，例如：
[root@localhost ~]# vmstat 2procs-----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpdfree buff cache si so bi bo in cs us sy idwa st0 0 384 1303264 215296 12506412 0 0 0 15 0 0 1 1 98 0 0
0 0 384 1303256 215296 12506412 0 0 0 0 237 201 0 0 99 0 0
0 0 384 1303000 215296 12506412 0 0 0 8 290 227 1 1 99 0 0
0 0 384 1302884 215296 12506412 0 0 0 0 227 206 0 1 99 0 0
0 0 384 1302628 215296 12506412 0 0 0 0 250 231 0 1 99 0 0
cs是每秒上下文切換的次數(shù)
in則是每秒鐘中斷的次數(shù)
r是就緒隊列的長度，也就是正在運行和等待CPU的進程數(shù)
b則是出于不可中斷睡眠狀態(tài)的進程數(shù)
可以看到，這個例子中的上線文切換次數(shù)cs是201次，而系統(tǒng)中斷in則是237次，而就緒隊列長度r和不可中斷狀態(tài)進程數(shù)b都是0。
vmstat只給出了系統(tǒng)總體的上下文切換情況，要向查看每個進程的詳細情況，就需要使用到pidstat了，如下：
[root@localhost ~]# pidstat -w 5Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4CPU)05:00:25 PM PID cswch/s nvcswch/s Command05:00:30 PM 3 0.20 0.00 migration/0
05:00:30 PM 4 0.20 0.00 ksoftirqd/0
05:00:30 PM 7 0.40 0.00 migration/1
05:00:30 PM 9 0.20 0.00 ksoftirqd/1
05:00:30 PM 13 0.20 0.00 ksoftirqd/2
05:00:30 PM 15 0.60 0.00 migration/3
05:00:30 PM 17 2.40 0.00 ksoftirqd/3
05:00:30 PM 19 1.20 0.00 events/0
05:00:30 PM 20 1.00 0.00 events/1
05:00:30 PM 21 1.00 0.00 events/2
05:00:30 PM 22 1.00 0.00 events/3
05:00:30 PM 28 0.20 0.00sync_supers05:00:30 PM 29 0.20 0.00 bdi-default05:00:30 PM 197 1.00 0.00mpt_poll_005:00:30 PM 353 0.20 0.00 flush-253:0
05:00:30 PM 598 1.00 0.00vmmemctl05:00:30 PM 1202 0.40 0.00master05:00:30 PM 1231 1.00 0.00zabbix_agentd05:00:30 PM 1235 1.00 0.00zabbix_agentd05:00:30 PM 2912 2.00 0.00bash05:00:30 PM 3360 10.98 0.00 redis-server05:00:30 PM 3748 1.00 0.20python05:00:30 PM 5830 0.40 0.00showq05:00:30 PM 5883 0.20 0.00pidstat05:00:30 PM 29194 1.00 1.60 apps.plugin
這個結(jié)果中有兩列內(nèi)容是我們重點關(guān)注的對象。一個是cswch，表示每秒自愿上下文切換的次數(shù)，另一個則是mbcswch，表示每秒非自愿上下文切換的次數(shù)。
這兩個概念意味著不同的性能問題：
自愿上下文切換，是指進程無法獲取所需自愿，導致上下文切換。比如，IO、內(nèi)存等系統(tǒng)資源不足時，就會發(fā)生自愿上下文切換。
非自愿上下文切換，則是指進程由于時間片已到等原因，被系統(tǒng)強制調(diào)度，進而發(fā)生的上下文切換。比如說，大量進程都在爭搶CPU時，就容易發(fā)生非自愿上下文切換。
模擬場景
使用sysbench來模擬系統(tǒng)多線程調(diào)度切換的情況。
sysbench是一個多線程的基準測試工具，一般用來評估不同系統(tǒng)參數(shù)下的數(shù)據(jù)庫負載情況，可以用來模擬上下文切換過多的問題。
測試前的數(shù)據(jù)查看情況
[root@localhost ~]# vmstat 1procs-----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpdfree buff cache si so bi bo in cs us sy idwa st0 0 384 1302564 215296 12506416 0 0 0 15 0 0 1 1 98 0 0
0 0 384 1302556 215296 12506416 0 0 0 0 257 207 1 1 99 0 0
0 0 384 1302556 215296 12506416 0 0 0 0 223 192 1 1 99 0 0
0 0 384 1302440 215296 12506416 0 0 0 0 257 219 1 1 99 0 0
0 0 384 1302176 215296 12506416 0 0 0 4 248 225 0 0 99 0 0
0 0 384 1302176 215296 12506416 0 0 0 0 218 203 1 1 99 0 0
0 0 384 1303044 215296 12506416 0 0 0 0 371 239 1 1 98 0 0
0 0 384 1302804 215296 12506416 0 0 0 0 232 213 0 1 99 0 0
在終端離運行sysbench，模擬系統(tǒng)多線程調(diào)度的瓶頸：
[root@localhost ~]# sysbench --threads=10 --max-time=300threads run
WARNING:--max-time is deprecated, use --timeinstead
sysbench1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads:10Initializing random number generator from currenttimeInitializing worker threads...
Threads started!
執(zhí)行sysbench后，使用vmstat來進行監(jiān)控：
[root@localhost ~]# vmstat 2procs-----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpdfree buff cache si so bi bo in cs us sy idwa st1 0 384 1297912 215400 12509840 0 0 0 15 0 0 1 1 98 0 0
2 0 384 1298036 215400 12509840 0 0 0 10 279 214 1 1 99 0 0
1 0 384 1298052 215400 12509840 0 0 0 0 241 202 1 1 99 0 0
8 0 384 1296716 215400 12509840 0 0 0 0 7069 257920 3 39 57 0 0
8 0 384 1296468 215400 12509840 0 0 0 0 17640 477390 7 80 13 0 0
10 0 384 1295592 215400 12509840 0 0 0 0 18891 657740 6 85 9 0 0
8 0 384 1295724 215400 12509840 0 0 0 0 19504 597917 7 82 11 0 0
觀測數(shù)據(jù)可以發(fā)現(xiàn)：
r列：就緒隊列的長度已經(jīng)到8，遠遠超過了系統(tǒng)CPU的個數(shù)2，所以肯定會有大量的CPU競爭。
us和sy列：這兩列的CPU使用率加起來上升到了100%，其中系統(tǒng)CPU使用率，也就是sy列高達80%左右，說明CPU主要是被內(nèi)核占用了。
in列：中斷次數(shù)也上升到了將近2萬左右，說明中斷處理也是個潛在的問題。
vmstat詳解如下：
綜合這幾個指標，可以知道，系統(tǒng)的就緒隊列過長，也就是正在運行和等待CPU的進程數(shù)過多，導致了大量的上下文切換，而上下文切換又導致了系統(tǒng)CPU的占用率升高。
使用pidstat來進行觀察，CPU和進程上下文的情況：
[root@localhost ~]# pidstat -w -u 1Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4CPU)05:25:40 PM PID %usr %system %guest %CPU CPU Command05:25:41 PM 17 0.00 0.98 0.00 0.98 3 ksoftirqd/3
05:25:41 PM 3360 0.98 0.98 0.00 1.96 1 redis-server05:25:41 PM 3723 1.96 0.98 0.00 2.94 1netdata05:25:41 PM 7661 28.43 100.00 0.00 100.00 1sysbench05:25:41 PM 7698 0.00 0.98 0.00 0.98 3pidstat05:25:41 PM 29194 0.98 0.98 0.00 1.96 1apps.plugin05:25:40 PM PID cswch/s nvcswch/s Command05:25:41 PM 4 7.84 0.00 ksoftirqd/0
05:25:41 PM 9 1.96 0.00 ksoftirqd/1
05:25:41 PM 13 10.78 0.00 ksoftirqd/2
05:25:41 PM 17 10.78 0.00 ksoftirqd/3
05:25:41 PM 19 0.98 0.00 events/0
05:25:41 PM 20 0.98 0.00 events/1
05:25:41 PM 21 0.98 0.00 events/2
05:25:41 PM 22 0.98 0.00 events/3
05:25:41 PM 29 0.98 0.00 bdi-default05:25:41 PM 61 0.98 0.00khugepaged05:25:41 PM 197 0.98 0.00mpt_poll_005:25:41 PM 598 0.98 0.00vmmemctl05:25:41 PM 1231 0.98 0.00zabbix_agentd05:25:41 PM 1235 0.98 0.00zabbix_agentd05:25:41 PM 3360 10.78 0.00 redis-server05:25:41 PM 3748 0.98 116.67python05:25:41 PM 7109 2.94 78.43bash05:25:41 PM 7698 0.98 1.96pidstat05:25:41 PM 29194 0.98 313.73 apps.plugin
從pidstat的輸出可以發(fā)現(xiàn)，CPU使用率的升高是由于sysbench導致的，它的CPU使用率已經(jīng)達到了100%，但上下文切換則是來自其他進程，包括自愿上下文切換頻率較高的redis-server和內(nèi)核進程ksoftirqd/2、ksoftirqd/3，以及非自愿上下文切換頻率比較高的python和apps.plugnin。
由于Linux調(diào)度的最小單位是線程，而sysbench模擬的也是線程的調(diào)度問題，因此vmstat顯示的中斷次數(shù)遠大于pidstat中顯示的次數(shù)，在pidstat后面加上選項-t，對線程進行監(jiān)控：如下
[root@localhost ~]# pidstat -w -t -u 1Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4CPU)06:05:28 PM TGID TID %usr %system %guest %CPU CPU Command06:05:29 PM 13 - 0.00 0.97 0.00 0.97 2 ksoftirqd/2
06:05:29 PM - 13 0.00 0.97 0.00 0.97 2 |__ksoftirqd/2
06:05:29 PM - 3726 0.00 0.97 0.00 0.97 1 |__netdata06:05:29 PM - 3738 0.00 0.97 0.00 0.97 2 |__netdata06:05:29 PM - 4020 0.00 0.97 0.00 0.97 0 |__python06:05:29 PM 10405 - 33.98 100.00 0.00 100.00 1sysbench06:05:29 PM - 10406 4.85 36.89 0.00 41.75 1 |__sysbench06:05:29 PM - 10407 2.91 31.07 0.00 33.98 2 |__sysbench06:05:29 PM - 10408 2.91 33.01 0.00 35.92 2 |__sysbench06:05:29 PM - 10409 2.91 33.98 0.00 36.89 2 |__sysbench06:05:29 PM - 10410 3.88 33.98 0.00 37.86 3 |__sysbench06:05:29 PM - 10411 3.88 33.01 0.00 36.89 2 |__sysbench06:05:29 PM - 10412 1.94 31.07 0.00 33.01 2 |__sysbench06:05:29 PM - 10413 4.85 33.01 0.00 37.86 3 |__sysbench06:05:29 PM - 10414 2.91 33.01 0.00 35.92 1 |__sysbench06:05:29 PM - 10415 3.88 34.95 0.00 38.83 0 |__sysbench06:05:29 PM 10428 - 0.97 1.94 0.00 2.91 0pidstat06:05:29 PM - 10428 0.97 1.94 0.00 2.91 0 |__pidstat06:05:29 PM 29194 - 0.00 0.97 0.00 0.97 2apps.plugin06:05:29 PM - 29194 0.00 0.97 0.00 0.97 2 |__apps.plugin06:05:28 PM TGID TID cswch/s nvcswch/s Command06:05:29 PM 4 - 9.71 0.00 ksoftirqd/0
06:05:29 PM - 4 9.71 0.00 |__ksoftirqd/0
06:05:29 PM 9 - 7.77 0.00 ksoftirqd/1
06:05:29 PM - 9 7.77 0.00 |__ksoftirqd/1
06:05:29 PM 13 - 7.77 0.00 ksoftirqd/2
06:05:29 PM - 13 7.77 0.00 |__ksoftirqd/2
06:05:29 PM 17 - 15.53 0.00 ksoftirqd/3
06:05:29 PM - 17 15.53 0.00 |__ksoftirqd/3
06:05:29 PM 19 - 0.97 0.00 events/0
06:05:29 PM - 19 0.97 0.00 |__events/0
06:05:29 PM 20 - 0.97 0.00 events/1
06:05:29 PM - 20 0.97 0.00 |__events/1
06:05:29 PM 21 - 0.97 0.00 events/2
06:05:29 PM - 21 0.97 0.00 |__events/2
06:05:29 PM 22 - 0.97 0.00 events/3
06:05:29 PM - 22 0.97 0.00 |__events/3
06:05:29 PM 28 - 0.97 0.00sync_supers06:05:29 PM - 28 0.97 0.00 |__sync_supers06:05:29 PM 197 - 0.97 0.00mpt_poll_006:05:29 PM - 197 0.97 0.00 |__mpt_poll_006:05:29 PM 598 - 0.97 0.00vmmemctl06:05:29 PM - 598 0.97 0.00 |__vmmemctl06:05:29 PM 1202 - 0.97 0.00master06:05:29 PM - 1202 0.97 0.00 |__master06:05:29 PM 1231 - 0.97 0.00zabbix_agentd06:05:29 PM - 1231 0.97 0.00 |__zabbix_agentd06:05:29 PM 1235 - 1.94 0.00zabbix_agentd06:05:29 PM - 1235 1.94 0.00 |__zabbix_agentd06:05:29 PM 3360 - 10.68 0.00 redis-server06:05:29 PM - 3360 10.68 0.00 |__redis-server06:05:29 PM - 3725 0.97 31.07 |__netdata06:05:29 PM - 3726 0.97 0.00 |__netdata06:05:29 PM - 3727 0.97 0.00 |__netdata06:05:29 PM - 3728 2.91 0.00 |__netdata06:05:29 PM - 3729 49.51 2.91 |__netdata06:05:29 PM - 3730 0.97 0.00 |__netdata06:05:29 PM - 3733 0.97 0.00 |__netdata06:05:29 PM - 3738 0.97 87.38 |__netdata06:05:29 PM - 3740 1.94 0.00 |__netdata06:05:29 PM - 3743 0.97 0.00 |__netdata06:05:29 PM - 3744 0.97 0.00 |__netdata06:05:29 PM - 3745 0.97 0.00 |__netdata06:05:29 PM - 3751 0.97 0.00 |__netdata06:05:29 PM 3748 - 0.97 0.00python06:05:29 PM - 3748 0.97 0.00 |__python06:05:29 PM - 4020 3.88 6.80 |__python06:05:29 PM - 4021 3.88 2.91 |__python06:05:29 PM 7109 - 0.97 52.43bash06:05:29 PM - 7109 0.97 52.43 |__bash06:05:29 PM 9337 - 1.94 0.00showq06:05:29 PM - 9337 1.94 0.00 |__showq06:05:29 PM - 10406 18642.72 45331.07 |__sysbench06:05:29 PM - 10407 20953.40 42127.18 |__sysbench06:05:29 PM - 10408 17404.85 44594.17 |__sysbench06:05:29 PM - 10409 18404.85 45963.11 |__sysbench06:05:29 PM - 10410 12807.77 61773.79 |__sysbench06:05:29 PM - 10411 19445.63 38708.74 |__sysbench06:05:29 PM - 10412 17883.50 40695.15 |__sysbench06:05:29 PM - 10413 17189.32 49639.81 |__sysbench06:05:29 PM - 10414 18169.90 45739.81 |__sysbench06:05:29 PM - 10415 14832.04 47845.63 |__sysbench06:05:29 PM 10428 - 0.97 96.12pidstat06:05:29 PM - 10428 0.97 96.12 |__pidstat06:05:29 PM - 21200 1.94 0.00 |__grafana-server06:05:29 PM - 21202 0.97 0.00 |__grafana-server06:05:29 PM - 21206 1.94 0.00 |__grafana-server06:05:29 PM - 21209 0.97 0.00 |__grafana-server06:05:29 PM - 25021 1.94 0.00 |__grafana-server06:05:29 PM 29194 - 0.97 150.49apps.plugin06:05:29 PM - 29194 0.97 150.49 |__apps.plugin
可以看到sysbench進程的上下文切換看起來并不多，但是sysbench的子線程的上下文切換次數(shù)卻很多，我們發(fā)現(xiàn)進程的上下文切換發(fā)生很多同時中斷次數(shù)也上升到將近2萬，具體是什么類型的中斷上升還需要繼續(xù)進行監(jiān)測。
由于中斷發(fā)生在內(nèi)核態(tài)，而pidstat只是一個進程的性能分析工具，因此他并不能提供任何關(guān)于中斷的詳細信息。因此需要從/proc/interrupts這個只讀文件中讀取。/proc實際上是Linux的一個虛擬文件系統(tǒng)，用于內(nèi)核空間與用戶空間之間的通信。/proc/interrupts就是這種通信機制的一部分，提供了一個只讀的中斷使用情況。
[root@localhost ~]# watch -d cat /proc/interrupts
[root@localhost~]# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU30: 117486 0 0 0 IO-APIC-edge timer1: 7 0 0 1 IO-APIC-edge i80427: 0 0 0 0 IO-APIC-edge parport08: 1 0 0 0 IO-APIC-edge rtc09: 0 0 0 0 IO-APIC-fasteoi acpi12: 108 1 0 0 IO-APIC-edge i804214: 0 0 0 0 IO-APIC-edge ata_piix15: 13 17 19 27 IO-APIC-edge ata_piix17: 3128770 3092486 3307137 3143451 IO-APIC-fasteoi ioc024: 0 0 0 0 PCI-MSI-edge pciehp25: 0 0 0 0 PCI-MSI-edge pciehp26: 0 0 0 0 PCI-MSI-edge pciehp27: 0 0 0 0 PCI-MSI-edge pciehp28: 0 0 0 0 PCI-MSI-edge pciehp29: 0 0 0 0 PCI-MSI-edge pciehp30: 0 0 0 0 PCI-MSI-edge pciehp31: 0 0 0 0 PCI-MSI-edge pciehp32: 0 0 0 0 PCI-MSI-edge pciehp33: 0 0 0 0 PCI-MSI-edge pciehp34: 0 0 0 0 PCI-MSI-edge pciehp35: 0 0 0 0 PCI-MSI-edge pciehp36: 0 0 0 0 PCI-MSI-edge pciehp37: 0 0 0 0 PCI-MSI-edge pciehp38: 0 0 0 0 PCI-MSI-edge pciehp39: 0 0 0 0 PCI-MSI-edge pciehp40: 0 0 0 0 PCI-MSI-edge pciehp41: 0 0 0 0 PCI-MSI-edge pciehp42: 0 0 0 0 PCI-MSI-edge pciehp43: 0 0 0 0 PCI-MSI-edge pciehp44: 0 0 0 0 PCI-MSI-edge pciehp45: 0 0 0 0 PCI-MSI-edge pciehp46: 0 0 0 0 PCI-MSI-edge pciehp47: 0 0 0 0 PCI-MSI-edge pciehp48: 0 0 0 0 PCI-MSI-edge pciehp49: 0 0 0 0 PCI-MSI-edge pciehp50: 0 0 0 0 PCI-MSI-edge pciehp51: 0 0 0 0 PCI-MSI-edge pciehp52: 0 0 0 0 PCI-MSI-edge pciehp53: 0 0 0 0 PCI-MSI-edge pciehp54: 0 0 0 0 PCI-MSI-edge pciehp55: 0 0 0 0 PCI-MSI-edge pciehp56: 12676123 621337444 15964441 14094017 PCI-MSI-edge eth0-rxtx-0
57: 12934876 27740827 549375875 13481933 PCI-MSI-edge eth0-rxtx-1
58: 12958840 27092299 22935606 555653407 PCI-MSI-edge eth0-rxtx-2
59: 533414281 24804405 22861636 20169043 PCI-MSI-edge eth0-rxtx-3
60: 0 0 0 0 PCI-MSI-edge eth0-event-4NMI:0 0 0 0 Non-maskable interrupts
LOC:3073899782 2932109969 2836889656 2806862212Local timer interrupts
SPU:0 0 0 0Spurious interrupts
PMI:0 0 0 0Performance monitoring interrupts
IWI:18 16 18 15IRQ work interrupts
RES:486603569 505967773 471350449 492621309Rescheduling interrupts
CAL:75258 1646 73324 1735Function call interrupts
TLB:33950017 55405448 32837754 52628068TLB shootdowns
TRM:0 0 0 0Thermal event interrupts
THR:0 0 0 0Threshold APIC interrupts
MCE:0 0 0 0Machine check exceptions
MCP:117332 117332 117332 117332Machine check polls
ERR:0MIS:0
通過觀察發(fā)現(xiàn)，變化速度最快的是重調(diào)度中斷RES，這個中斷類型表示，喚醒空閑狀態(tài)的CPU來調(diào)度薪的任務(wù)運行，這是多處理器系統(tǒng)中，調(diào)度器用來分散任務(wù)導不同CPU的機制，通常也被稱為處理器間中斷
所以，這里的中斷升高還是因為過多任務(wù)的調(diào)度問題，跟前面上下文切換次數(shù)的分析結(jié)果是一致的。
上下文切換正常的數(shù)值取決于系統(tǒng)本身的CPU性能。如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定，那么從數(shù)百到1萬以內(nèi)，都應(yīng)該算是正常。當上下文切換次數(shù)超過一萬次，或者切換次數(shù)出現(xiàn)數(shù)量級的增長時，就很有可能出現(xiàn)了性能問題。
這個時候需要依據(jù)上下文切換的類型，在做具體分析：
自愿上下文切換變多了，說明進程都在等待自愿，有可能發(fā)生了IO等其他問題；
非自愿上下文切換變多了，說明進程都在被強制調(diào)度，也就是都在爭搶CPU，說明CPU的確成了瓶頸；
中斷次數(shù)變多了，說明CPU被中斷處理程序占用了，還需要通過查看/proc/interrupts文件來分析具體的中斷類型
CPU性能分析優(yōu)化
CPU使用率
Linux作為一個多任務(wù)操作系統(tǒng)，將每個CPU的時間劃分為很短的時間片，再通過調(diào)度器輪流分配給各個任務(wù)使用，因此造成多任務(wù)同時運行的錯覺。
為了維護CPU時間，Linux通過事先定義的節(jié)拍率(內(nèi)核中表示為HZ)，觸發(fā)時間中斷，并使用全局變量Jiffies記錄了開機以來的節(jié)拍數(shù)。每發(fā)生一次時間中斷，Jiffies的值就加1。
節(jié)拍率HZ是內(nèi)核的可配選項，可以配置為100、250、1000等。不同的系統(tǒng)可能設(shè)置不同的數(shù)值，可以通過查詢/boot/config內(nèi)核選項來查看它的配置(CONFIG_HZ=1000)。比如在我的服務(wù)器系統(tǒng)中，節(jié)拍率設(shè)置成了1000，也就是每秒鐘觸發(fā)1000次時間中斷。
[root@localhost ~]# grep 'CONFIG_HZ=' /boot/config-2.6.32-431.el6.x86_64
CONFIG_HZ=1000
正因為節(jié)拍率HZ是內(nèi)核選項，所以用戶空間程序并不能直接訪問。為了方便用戶空間程序，內(nèi)核還提供了一個用戶空間節(jié)拍率USER_HZ，它總是固定為100，也就是1/100秒。這樣，用戶空間程序并不需要關(guān)心內(nèi)核中HZ被設(shè)置成了多少，因為它看到的總是固定值USER_HZ。
Linux通過/proc虛擬文件系統(tǒng)，向用戶空間提供了系統(tǒng)內(nèi)部狀態(tài)的信息，而/proc/stat提供的就是系統(tǒng)的CPU和任務(wù)統(tǒng)計信息。如果只需要關(guān)注CPU，可以執(zhí)行如下命令：
[root@localhost ~]# cat /proc/stat |grep ^cpu
cpu182993898 729 117810616 13772680802 1631791 13585 2713967 0 0cpu044712915 43 27980485 3442961333 378691 3216 649777 0 0cpu145582701 297 30219438 3442511274 419280 3848 738211 0 0cpu246830450 48 28005111 3445732783 420358 3273 676506 0 0cpu345867831 339 31605580 3441475411 413462 3246 649470 0 0
這里輸出結(jié)果是一個表格。其中，第一列表示的是CPU編號，如cpu0、cpu1、cpu2、cpu3，而第一行沒有編號的cpu，表示的是所有CPU的累加。而其他列表示不同場景下CPU的累加節(jié)拍數(shù)，她的單位是USER_HZ，也就是10ms(1/100秒)，所以這其實就是不同場景下的CPU時間。
user(通常縮寫為us)，代表用戶態(tài)CPU時間。注意，它不包含下面的nice時間，但包括了gust時間。
nice(通常縮寫為ni)，代表低級優(yōu)先級用戶態(tài)CPU時間，也就是進程的nice值被調(diào)整為1-19之間的CPU時間，這里注意nice可取值范圍是-20到19，數(shù)值越大，優(yōu)先級反而越低。
system(通常縮寫為sys)，代表內(nèi)核態(tài)CPU時間。
idle(通常縮寫為id)，代表空閑時間。注意，它不包括等待IO的時間(iowait)。
iowait(通常縮寫為wa)，代表等待IO的CPU時間。
irq(通常縮寫為hi)，代表處理硬中斷的CPU時間。
softirq(通常縮寫為si)，代表處理軟中斷的CPU時間。
steal(通常縮寫為st)，代表當系統(tǒng)運行在虛擬機中的時候，被其他虛擬機占用的CPU時間。
guest(通常縮寫為guest)，代表通過虛擬化運行其他操作系統(tǒng)的時間，也就是運行虛擬機的CPU時間、
guest_nice(通常縮寫為gnice)，代表低優(yōu)先級運行虛擬機的時間。
通常所說的CPU使用率，就是除了空閑時間外的其他時間占用CPU時間的百分比，用公式表示就是
根據(jù)這個公式，我們就可以從/proc/stat中的數(shù)據(jù)，很容易地計算出CPU使用率。當然，也可以用每一個場景的CPU時間，除以總的CPU時間，計算出每個場景的CPU使用率。
查看/proc/stat中的數(shù)據(jù)，顯示的是開機以來的節(jié)拍數(shù)累加值，所以直接算出來的，是開機以來的平均CPU使用率，一般沒有什么參考價值。
事實上，為了計算CPU使用率，性能工具一般都會間隔一段時間的兩次值，作差后，再計算出這段時間內(nèi)平均CPU使用率。
這個公式，就是我們用各種性能工具所看到的CPU使用率的實際計算方法。
進程的CPU使用率方法與系統(tǒng)指標類似，Linux也給每個進程提供了運行情況的統(tǒng)計信息，也就是/proc/[pid]/stat。不過，這個文件包含的數(shù)據(jù)就比較豐富了，總共有52列的數(shù)據(jù)。
性能分析工具給出的都是間隔一段時間的平均CPU使用率，所以要注意間隔時間的設(shè)置，特別是用多個工具對比分析時，你一定要保證他們用的是相同的間隔時間。
比如，對比一下top和ps這兩個工具報告的CPU使用率，默認的結(jié)果很可能不一樣，因為top默認使用3秒時間間隔，而ps使用的卻是進程的整個生命周期。
查看CPU使用率
top和ps是最常用的性能分析工具：
top顯示了系統(tǒng)總體的CPU和內(nèi)存使用情況，以及各個進程的資源使用情況。
ps則只顯示了每個進程的資源使用情況。
關(guān)于top命令使用見下圖詳解
top命令每個進程都有一個%CPU列，表示進程的CPU使用率。它是用戶態(tài)和內(nèi)核態(tài)CPU使用率的總和，包括進程用戶空間使用的CPU、通過系統(tǒng)調(diào)用執(zhí)行的內(nèi)核空間CPU、以及在就緒隊列等待運行的CPU。在虛擬化環(huán)境中，它還包括了運行虛擬機占用的CPU，可以發(fā)現(xiàn)top命令并沒有細分進程的用戶態(tài)CPU和內(nèi)核態(tài)CPU。
如果想要查看進程CPU使用率的具體情況需要使用pidstat命令來進行觀測；
[root@localhost ~]# pidstat 1 5Linux2.6.32-431.el6.x86_64 (localhost.localdomain) 04/30/2020 _x86_64_ (4CPU)02:29:12 PM PID %usr %system %guest %CPU CPU Command02:29:13 PM 14734 0.00 0.98 0.00 0.98 3apps.plugin02:29:13 PM 29918 0.98 0.98 0.00 1.96 1pidstat02:29:13 PM PID %usr %system %guest %CPU CPU Command02:29:14 PM 3360 0.00 1.00 0.00 1.00 0 redis-server02:29:14 PM 3723 1.00 0.00 0.00 1.00 0netdata02:29:14 PM 14734 1.00 0.00 0.00 1.00 3apps.plugin02:29:14 PM 21198 1.00 0.00 0.00 1.00 1 grafana-server02:29:14 PM 29167 0.00 1.00 0.00 1.00 2bash02:29:14 PM 29918 0.00 1.00 0.00 1.00 1pidstat02:29:14 PM PID %usr %system %guest %CPU CPU Command02:29:15 PM 3748 1.00 0.00 0.00 1.00 0python02:29:15 PM 14734 0.00 1.00 0.00 1.00 3apps.plugin02:29:15 PM 29918 0.00 1.00 0.00 1.00 1pidstat02:29:15 PM PID %usr %system %guest %CPU CPU Command02:29:16 PM 3723 1.00 0.00 0.00 1.00 0netdata02:29:16 PM 14734 0.00 1.00 0.00 1.00 3apps.plugin02:29:16 PM 21198 0.00 1.00 0.00 1.00 1 grafana-server02:29:16 PM 29167 1.00 0.00 0.00 1.00 1bash02:29:16 PM 29918 1.00 0.00 0.00 1.00 1pidstat02:29:16 PM PID %usr %system %guest %CPU CPU Command02:29:17 PM 3360 1.00 0.00 0.00 1.00 0 redis-server02:29:17 PM 3723 1.00 1.00 0.00 2.00 0netdata02:29:17 PM 14734 1.00 0.00 0.00 1.00 3apps.plugin02:29:17 PM 29918 0.00 1.00 0.00 1.00 1pidstat
Average: PID%usr %system %guest %CPU CPU Command
Average:3360 0.20 0.20 0.00 0.40 - redis-server
Average:3723 0.60 0.20 0.00 0.80 -netdata
Average:3748 0.20 0.00 0.00 0.20 -python
Average:14734 0.40 0.60 0.00 1.00 -apps.plugin
Average:21198 0.20 0.20 0.00 0.40 - grafana-server
Average:29167 0.20 0.20 0.00 0.40 -bash
Average:29918 0.40 0.80 0.00 1.20 - pidstat
如上面的pidstat命令，就間隔1秒展示了進程的5組CPU使用率，包括
用戶態(tài)CPU使用率(%usr)
內(nèi)核態(tài)CPU使用率(%system)；
運行虛擬機CPU使用率(%guest)；
等待CPU使用率(%wait)；
以及總的CPU使用率(%CPU)
最后Average部分，還計算了5組數(shù)據(jù)的平均值。
CPU使用率分析
perf是Linux2.6.31以后內(nèi)置的性能分析工具，它以性能時間采樣為基礎(chǔ)，不僅可以分析系統(tǒng)的各種事件和內(nèi)核性能，還可以用來分析指定應(yīng)用程序的性能問題。
[root@localhost ~]# perf top
Samples: 11K of event'cpu-clock', Event count (approx.):1015Overhead Shared Object Symbol9.42%[kernel] [k] kallsyms_expand_symbol7.03%perf [.] symbols__insert6.37%perf [.] rb_next4.51%[kernel] [k] vsnprintf4.11%[kernel] [k] format_decode3.71%[kernel] [k] number3.45%[kernel] [k] strnlen2.79% [kernel] [k] string
2.52%perf [.] hex2u642.12% libc-2.14.so [.] __strcmp_sse421.99% libc-2.14.so [.] __memcpy_sse21.86% libc-2.14.so [.] _int_malloc1.59% libc-2.14.so [.] _IO_getdelim1.59% libc-2.14.so [.] __strchr_sse421.46% libc-2.14.so [.] __libc_calloc1.33% libc-2.14.so [.] __strstr_sse421.19%[kernel] [k] get_task_cred1.19%[kernel] [k] update_iter1.06%[kernel] [k] module_get_kallsym1.06% libpthread-2.14.so [.] pthread_rwlock_rdlock
輸出結(jié)果中，第一行包含三個數(shù)據(jù)，分別是采樣數(shù)(Sample)、事件類型(event)和事件總數(shù)量(Event count)。例子中，pref總共采集了11K個CPU時鐘事件，需要注意如果采樣數(shù)過少，那下面的排序和百分比就沒什么實際參考價值。
第一列Overhead，是該符號的性能事情在所有采用中的比例，用百分比來表示。
第二列Shared，是該函數(shù)或指令所在的動態(tài)共享對象，如內(nèi)核、進程名、動態(tài)鏈接庫名、內(nèi)核模塊名等。
第三列Object，是動態(tài)共享對象的類型。比如[.]表示用戶空間的可執(zhí)行程序、或者動態(tài)鏈接庫，而[k]則表示內(nèi)核空間。
最后一列Symbol是符號名，也就是函數(shù)名。當函數(shù)名未知時，用十六進制的地址來表示。
從上面數(shù)據(jù)，可以看到，占用CPU時鐘最多的是kernel(內(nèi)核)，不過它的比例也只有9.42%，說明系統(tǒng)并沒有CPU性能問題。
系統(tǒng)進程分析
進程狀態(tài)
參考ps命令詳解，這里不再多說
總結(jié)
以上是生活随笔為你收集整理的python linux 优化_Linux性能优化(一)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 同步滚动两个DataGrid
- 下一篇： linux下hg无法运行_在 Windo