性能指標
性能優化的兩個核心指標——"吞吐"和"延遲"，這是從應用負載的視角來進行考察系統性能，直接影響了產品終端的用戶體驗。與之對應的是從系統資源的視角出發的指標，比如資源使用率、飽和度等。
我們知道，隨着應用負載的增加，系統資源的使用也會升高，甚至達到極限。而性能問題的本質，就是系統資源已經達到瓶頸，但請求的處理卻還不夠快，無法支撐更多的請求。
性能分析，其實就是找出應用或系統的瓶頸，並設法去避免或者緩解他們，從而更高效地利用系統資源處理更多的請求。這包含了一系列的步驟，比如下面這六個步驟。
-
選擇指標評估應用程序和系統的性能
-
為應用程序和系統設置性能目標
-
進行性能基准測試
-
性能分析定位瓶頸
-
優化系統和應用程序
-
性能監控和告警
這個圖是Linux性能分析最重要的參考資料之一，它告訴你，在Linux不同子系統出現性能問題后，應該用什么樣的工具來觀測和分析。
比如，當遇到IO性能問題時，可以參考圖片下方的IO子系統，使用iostat、iotop、blktrace等工具分析磁盤IO的瓶頸。
理解平均負載
平均負載
平均負載是指單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和CPU使用率並沒有直接關系。
可運行狀態的進程，是指正在使用CPU或者正在等待CPU的進程，也就是ps命令查看進程狀態中的R狀態（Running或Runnable）。
不可中斷狀態的進程，是指正處於內核態關鍵流程中的進程，並且這些流程是不可打斷的，比如最長間的是等待硬件設備的IO響應，也就是ps命令查看進程狀態中的D狀態。例如，當一個進程向磁盤讀取數據時，為了保證數據的一致性，在得到磁盤回復前，它是不能被其他進程或者中斷打斷，這個時候的進程處於不可中斷狀態。如果此時的進程被打斷，就容易出現磁盤數據與進程數據不一致的問題。所以，不可中斷狀態實際上是系統對進程和硬件設備的一種保護機制。因此平均負載可以理解為平均活躍進程數。平均進程活躍數，直觀上的理解就是單位時間內的活躍進程數，但實際上是活躍進程數的指數衰減平均值，可以直接理解為活躍進程數的平均值。
如果當平均負載為2時，就意味着
-
在只有2個CPU的系統上，意味着所有的CPU都剛好被完全占用。
-
在4個CPU的系統上，意味着CPU有50%的空閑。
-
在1個CPU的系統中，意味着有一半的進程競爭不到CPU
平均負載為多少時合理
平均負載最理想的情況是等於CPU個數，所以在評判平均負載時，首先要知道系統有幾個CPU，有了CPU個數，我們可以判斷出，當平均負載比CPU個數還大的時候，系統已經出現了過載。
三個不同時間間隔的平均負載，其實給我們提供了，分析系統負載趨勢的數據來源，讓我們更能全面、更立體地理解目前的負載情況。
-
如果1分鍾、5分鍾、15分鍾的三個值基本相同，或者相差不大，那就說明系統負載很平穩。
-
但如果1分鍾的值遠小於15分鍾的值，就說明系統最近1分鍾的負載在減少，而過去15分鍾內卻有很大的負載
-
如果1分鍾的值遠大於15分鍾的值，就說明最近1分鍾的負載在增加，這種增加有可能只是臨時性的，也有可能還會持續增加下去，所以就需要持續觀察。一旦1分鍾的平均負載接近或者超過CPU的個數，就意味着系統正在發生過載的問題，這時就得分析調查是哪里導致的問題，並要想辦法優化。
分析排查負載過高的問題需要把系統的平均負載監控起來，然后根據更多的歷史數據，判斷負載的變化趨勢，當發生負載有明顯升高趨勢時，比如說負載翻倍了，再去做分析和調查
平均負載與CPU使用率
-
CPU密集型進程，使用大量CPU會導致平均負載升高
-
IO密集型進程，等待IO也會導致平均負載升高，單CPU使用率不一定很高。
-
大量等待CPU的進程調度也會導致平均負載升高，此時的CPU使用率也會比較高。
分析負載工具
CPU場景監控
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、內存、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分鍾內的平均負載==1，而mpstat命令看到CPU1的使用率為100%，且都是在用戶態空間使用的CPU，說明導致負載升高是由於CPU使用率比較高引起的負載升高；最后使用pidstat監測，發現是stress進程CPU使用為100%
IO密集型應用
[root@localhost ~]# stress -i 1 --timeout 600 stress: info: [7582] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd [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 1 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_ (4 CPU) 06:17:07 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 06: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.59 Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle Average: all 0.35 0.00 24.90 0.05 0.00 0.00 0.00 0.00 74.70 Average: 0 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 99.60 Average: 1 0.00 0.00 97.79 0.00 0.00 0.00 0.00 0.00 2.21 Average: 2 0.40 0.00 1.20 0.00 0.00 0.00 0.00 0.00 98.40 Average: 3 0.81 0.00 0.60 0.00 0.00 0.00 0.00 0.00 98.59 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/27/2020 _x86_64_ (4 CPU) Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 6.62 0.00 0.28 0.10 55.18 197.39 0.00 16.34 17.61 16.33 2.20 0.06 sdb 0.00 8.30 0.00 0.14 0.09 67.52 466.32 0.00 19.77 11.13 19.87 1.55 0.02 dm-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.08 dm-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
可以看到結合iostat分析發現導致負載升高的是IO導致系統負載升高
[root@localhost ~]# stress -c 8 --timeout 600 stress: info: [8429] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd
利用stress -c 8 --timeout 600可以模擬更加復雜的場景
Linux是一個多任務操作系統，它支持遠大於CPU數量的任務同時運行。當然，這些任務實際上並不是真的在同時運行，而是因為系統在很短的時間內，將CPU輪流分配給它們，造成多任務同時運行的錯覺。每個任務運行前，CPU都需要知道任務從哪里加載，又從哪里開始運行，也就是說，需要系統事先幫它設置好CPU寄存器和程序計數器。CPU寄存器，是CPU內置的容量小，但速度極快的內存。程序計數器，則是用來存儲CPU正在執行的指令位置，或者即將執行的下一條指令位置。它們都是CPU在運行任務前，必須的依賴環境，因此也被叫做CPU上下文。
CPU上下文切換，就是先把前一個任務的CPU上下文保存起來，然后加載新任務的上下文到這些寄存器和程序計數器，最后再跳轉到程序計數器所指的新位置，運行新任務。而這些保存下來的上下文，會存儲在系統內核中，並在任務重新調度執行時再次加載進來。這樣就能保證任務原來的狀態不受影響，讓任務看起來還是連續執行。
根據任務的不同，CPU的上下文切換就可以分為進程上下文切換、線程上下文切換以及中斷上下文切換。
Linux按照特權等級，把進程的運行空間分為內核空間和用戶空間，分別對應着下圖中，CPU特權等級的Ring0和Ring3。
-
內核空間(Ring0)具有最高權限，可以直接訪問所有資源；
-
用戶空間(Ring3)只能訪問受限資源，不能直接訪問內存等硬件設備，必須通過系統調用陷入到內核中，才能訪問這些特權資源。
也就是說，進程既可以在用戶空間運行，又可以在內核空間中運行。進程在用戶空間運行時，被稱為進程的用戶態，而陷入內核空間的時候，被稱為進程的內核態。
從用戶態到內核態的轉變，需要通過系統調用來完成。比如，當我們查看文件內容時，就需要多次系統調用來完成：首先調用open()打開文件，然后調用read()讀取文件內容，並調用write()將內容寫到標准輸出，最后再調用close()關閉文件。
CPU寄存器里原來用戶態的指令位置，需要先保存起來。接着，為了執行內核態代碼，CPU寄存器需要更新為內核態指令的新位置，最后才是跳轉到內核態運行內核任務。
而系統調用結束后，CPU寄存器需要恢復原來保存的用戶態，然后在切換到用戶空間，繼續運行進程。所以，一次系統調用的過程，其實是發生了兩次CPU上下文切換。
不過，需要注意的是，系統調用過程中，並不會涉及到虛擬內存等進程用戶的資源，也不會切換進程。這與我們通常所說的進程上下文切換是不一樣的：
-
進程上下文切換，是指從一個進程切換到另一個進程運行。
-
而系統調用過程中一直是同一個進程在運行。
所以，系統調用過程通常稱為特權模式切換，而不是上下文切換。但實際上，系統調用過程中，CPU的上下文切換還是無法避免的。
進程上下文切換跟系統調用的區別：
首先，需要知道，進程是由內核來管理和調度的，進程的切換只能發生在內核態。所以，進程的上下文不僅包括了虛擬內存、棧、全局變量等用戶空間的資源，還包括了內核堆棧、寄存器等內核空間的狀態。
因此，進程上下文切換就比系統調用多了一步：在保存當前進程的內核狀態和CPU寄存器之前，需要先把該進程的虛擬內存、棧等保存下來；而加載了下一進程的內核態后，還需要刷新進程的虛擬內存和用戶棧。
如下圖所示，保存上下文和恢復上下文的過程並不是免費的，需要內核在CPU上運行才能完成。
根據研究表明，每次上下文切換都需要幾十納秒到數微秒的CPU時間，這個時間還是相當可觀的，特別是在進程上下文切換次數較多的情況下，很容易導致CPU將大量時間耗費在寄存器、內核棧以及虛擬內存等資源的保存和恢復上，進而大大縮短了真正運行進程的時間。這也是導致平均負載上升的一個重要因素。
Linux通過TLB來管理虛擬內存到物理內存的映射關系。當虛擬內存更新后，TLB也需要刷新，內存的訪問也會隨之變慢。特別是在多處理系統上，緩存是被多個處理器共享的，刷新緩存不僅會影響當前處理器的進程，還會影響共享緩存的其他處理器的進程。
顯然，進程切換時才需要切換上下文，換句話說，只有在進程調度的時候，才需要切換上下文。Linux為每個CPU都維護了一個就緒隊列，將活躍進程(即正在運行和正在等待CPU的進程)按照優先級和等待CPU的時間排序，然后選擇最需要CPU的進程，這也就是優先級最高和等待CPU時間最長的進程來運行。
觸發進程調度的場景：
-
為了保證所有進程可以得到公平調度，CPU時間被划分為一段段的時間片，這些時間片再被輪流分配給各個進程。這樣，當某個進程的時間片耗盡了，就會被系統掛起，切換到其它正在等待CPU的進程執行。
-
進程在系統資源不足時，要等到資源滿足后才可以運行，這個時候進程也會被掛起，並由系統調度其它進程運行。
-
當進程通過睡眠函數sleep這樣的方法將自己主動掛起時，自然也會重新調度。
-
當有優先級更高的進程運行時，為了保證高優先級進程的運行，當前進程會被掛起，由高優先級進程來運行。
-
當發生硬中斷時，CPU上的進程會被掛起，轉而執行內核中的中斷服務程序。
線程上下文切換
線程與進程最大的區別在於，線程是調度的基本單位，而進程則是資源擁有的基本單位。所謂內核中的任務調度，實際上的調度對象是線程；而進程只是給線程提供了虛擬內存、全局變量等資源。所以，對於線程和進程可以這么理解：
-
當進程只有一個線程時，可以認為進程就等於線程。
-
當進程擁有多個線程時，這些線程會共享相同的虛擬內存和全局變量等資源。這些資源在上下文切換時是不需要修改的。
-
線程也有自己的私有數據，比如棧和寄存器等，這些在上下文切換時也是需要保存的。
因此，線程的上下文切換其實就可以分為兩種情況：
第一種，前后兩個線程屬於不同進程。此時，資源不同享，所以切換過程就跟進程上下文切換是一樣的。
第二種，前后兩個線程屬於同一個進程。此時，虛擬內存是共享的，所以在切換時，虛擬內存這些資源就保持不動，只需要切換線程的私有數據、寄存器等不同享數據。
通過以上情況可以發現，雖然同為上下文切換，但同進程內的線程切換，要比多進程間切換消耗更少的資源，而這，也正是多線程代替多進程的一個優勢。
中斷上下文切換
切換進程CPU上下文，其實就是中斷上下文切換。為了快速響應硬件的事件，中斷處理會打斷進程的正常調度和執行，轉而調用中斷處理程序，響應設備事件。而在打斷其他進程時，就需要將進程當前狀態保存下來，這樣在中斷結束后，進程仍然可以從原來的狀態恢復運行。
跟進程上下文不同，中斷上下文切換並不涉及到進程的用戶態。所以，即便中斷過程打斷了一個正處在用戶態的進程，也不需要保存和恢復這個進程的虛擬內存、全局變量等用戶態資源。中斷上下文，其實只包括內核態中斷服務程序執行所必須的狀態，包括CPU寄存器、內核堆棧、硬件中斷參數等。
對同一個CPU來說，中斷處理比進程擁有更高的優先級，所以中斷上下文切換並不會與進程上下文切換同時發生。同樣道理，由於中斷會打斷正常進程的調度和執行，所以大部分中斷處理程序都短小精悍，以便盡可能快的執行結束。
另外，跟進程上下文切換一樣，中斷上下文切換也需要消耗CPU，切換次數過多也會消耗大量的CPU，甚至嚴重降低系統的整體性能。所以，當發現中斷次數過多時，就需要注意去排查它是否會給系統帶來嚴重的性能問題。
CPU上下文切換分析
查看系統上下文
利用vmstat工具來進行查看上下文切換，例如：
[root@localhost ~]# vmstat 2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 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是每秒上下文切換的次數
-
in則是每秒鍾中斷的次數
-
r是就緒隊列的長度，也就是正在運行和等待CPU的進程數
-
b則是出於不可中斷睡眠狀態的進程數
可以看到，這個例子中的上線文切換次數cs是201次，而系統中斷in則是237次，而就緒隊列長度r和不可中斷狀態進程數b都是0。
vmstat只給出了系統總體的上下文切換情況，要向查看每個進程的詳細情況，就需要使用到pidstat了，如下：
[root@localhost ~]# pidstat -w 5 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4 CPU) 05:00:25 PM PID cswch/s nvcswch/s Command 05: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.00 sync_supers 05:00:30 PM 29 0.20 0.00 bdi-default 05:00:30 PM 197 1.00 0.00 mpt_poll_0 05:00:30 PM 353 0.20 0.00 flush-253:0 05:00:30 PM 598 1.00 0.00 vmmemctl 05:00:30 PM 1202 0.40 0.00 master 05:00:30 PM 1231 1.00 0.00 zabbix_agentd 05:00:30 PM 1235 1.00 0.00 zabbix_agentd 05:00:30 PM 2912 2.00 0.00 bash 05:00:30 PM 3360 10.98 0.00 redis-server 05:00:30 PM 3748 1.00 0.20 python 05:00:30 PM 5830 0.40 0.00 showq 05:00:30 PM 5883 0.20 0.00 pidstat 05:00:30 PM 29194 1.00 1.60 apps.plugin
這個結果中有兩列內容是我們重點關注的對象。一個是cswch，表示每秒自願上下文切換的次數，另一個則是mbcswch，表示每秒非自願上下文切換的次數。
這兩個概念意味着不同的性能問題：
-
自願上下文切換，是指進程無法獲取所需自願，導致上下文切換。比如，IO、內存等系統資源不足時，就會發生自願上下文切換。
-
非自願上下文切換，則是指進程由於時間片已到等原因，被系統強制調度，進而發生的上下文切換。比如說，大量進程都在爭搶CPU時，就容易發生非自願上下文切換。
模擬場景
使用sysbench來模擬系統多線程調度切換的情況。
sysbench是一個多線程的基准測試工具，一般用來評估不同系統參數下的數據庫負載情況，可以用來模擬上下文切換過多的問題。
測試前的數據查看情況
[root@localhost ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 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，模擬系統多線程調度的瓶頸：
[root@localhost ~]# sysbench --threads=10 --max-time=300 threads run WARNING: --max-time is deprecated, use --time instead sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 10 Initializing random number generator from current time Initializing worker threads... Threads started!
執行sysbench后，使用vmstat來進行監控：
[root@localhost ~]# vmstat 2 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 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
觀測數據可以發現：
-
r列：就緒隊列的長度已經到8，遠遠超過了系統CPU的個數2，所以肯定會有大量的CPU競爭。
-
us和sy列：這兩列的CPU使用率加起來上升到了100%，其中系統CPU使用率，也就是sy列高達80%左右，說明CPU主要是被內核占用了。
-
in列：中斷次數也上升到了將近2萬左右，說明中斷處理也是個潛在的問題。
vmstat詳解如下：
綜合這幾個指標，可以知道，系統的就緒隊列過長，也就是正在運行和等待CPU的進程數過多，導致了大量的上下文切換，而上下文切換又導致了系統CPU的占用率升高。
[root@localhost ~]# pidstat -w -u 1 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4 CPU) 05:25:40 PM PID %usr %system %guest %CPU CPU Command 05: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-server 05:25:41 PM 3723 1.96 0.98 0.00 2.94 1 netdata 05:25:41 PM 7661 28.43 100.00 0.00 100.00 1 sysbench 05:25:41 PM 7698 0.00 0.98 0.00 0.98 3 pidstat 05:25:41 PM 29194 0.98 0.98 0.00 1.96 1 apps.plugin 05:25:40 PM PID cswch/s nvcswch/s Command 05: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-default 05:25:41 PM 61 0.98 0.00 khugepaged 05:25:41 PM 197 0.98 0.00 mpt_poll_0 05:25:41 PM 598 0.98 0.00 vmmemctl 05:25:41 PM 1231 0.98 0.00 zabbix_agentd 05:25:41 PM 1235 0.98 0.00 zabbix_agentd 05:25:41 PM 3360 10.78 0.00 redis-server 05:25:41 PM 3748 0.98 116.67 python 05:25:41 PM 7109 2.94 78.43 bash 05:25:41 PM 7698 0.98 1.96 pidstat 05:25:41 PM 29194 0.98 313.73 apps.plugin
從pidstat的輸出可以發現，CPU使用率的升高是由於sysbench導致的，它的CPU使用率已經達到了100%，但上下文切換則是來自其他進程，包括自願上下文切換頻率較高的redis-server和內核進程ksoftirqd/2、ksoftirqd/3，以及非自願上下文切換頻率比較高的python和apps.plugnin。
由於Linux調度的最小單位是線程，而sysbench模擬的也是線程的調度問題，因此vmstat顯示的中斷次數遠大於pidstat中顯示的次數，在pidstat后面加上選項-t，對線程進行監控：如下
[root@localhost ~]# pidstat -w -t -u 1 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/29/2020 _x86_64_ (4 CPU) 06:05:28 PM TGID TID %usr %system %guest %CPU CPU Command 06: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 |__netdata 06:05:29 PM - 3738 0.00 0.97 0.00 0.97 2 |__netdata 06:05:29 PM - 4020 0.00 0.97 0.00 0.97 0 |__python 06:05:29 PM 10405 - 33.98 100.00 0.00 100.00 1 sysbench 06:05:29 PM - 10406 4.85 36.89 0.00 41.75 1 |__sysbench 06:05:29 PM - 10407 2.91 31.07 0.00 33.98 2 |__sysbench 06:05:29 PM - 10408 2.91 33.01 0.00 35.92 2 |__sysbench 06:05:29 PM - 10409 2.91 33.98 0.00 36.89 2 |__sysbench 06:05:29 PM - 10410 3.88 33.98 0.00 37.86 3 |__sysbench 06:05:29 PM - 10411 3.88 33.01 0.00 36.89 2 |__sysbench 06:05:29 PM - 10412 1.94 31.07 0.00 33.01 2 |__sysbench 06:05:29 PM - 10413 4.85 33.01 0.00 37.86 3 |__sysbench 06:05:29 PM - 10414 2.91 33.01 0.00 35.92 1 |__sysbench 06:05:29 PM - 10415 3.88 34.95 0.00 38.83 0 |__sysbench 06:05:29 PM 10428 - 0.97 1.94 0.00 2.91 0 pidstat 06:05:29 PM - 10428 0.97 1.94 0.00 2.91 0 |__pidstat 06:05:29 PM 29194 - 0.00 0.97 0.00 0.97 2 apps.plugin 06:05:29 PM - 29194 0.00 0.97 0.00 0.97 2 |__apps.plugin 06:05:28 PM TGID TID cswch/s nvcswch/s Command 06: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.00 sync_supers 06:05:29 PM - 28 0.97 0.00 |__sync_supers 06:05:29 PM 197 - 0.97 0.00 mpt_poll_0 06:05:29 PM - 197 0.97 0.00 |__mpt_poll_0 06:05:29 PM 598 - 0.97 0.00 vmmemctl 06:05:29 PM - 598 0.97 0.00 |__vmmemctl 06:05:29 PM 1202 - 0.97 0.00 master 06:05:29 PM - 1202 0.97 0.00 |__master 06:05:29 PM 1231 - 0.97 0.00 zabbix_agentd 06:05:29 PM - 1231 0.97 0.00 |__zabbix_agentd 06:05:29 PM 1235 - 1.94 0.00 zabbix_agentd 06:05:29 PM - 1235 1.94 0.00 |__zabbix_agentd 06:05:29 PM 3360 - 10.68 0.00 redis-server 06:05:29 PM - 3360 10.68 0.00 |__redis-server 06:05:29 PM - 3725 0.97 31.07 |__netdata 06:05:29 PM - 3726 0.97 0.00 |__netdata 06:05:29 PM - 3727 0.97 0.00 |__netdata 06:05:29 PM - 3728 2.91 0.00 |__netdata 06:05:29 PM - 3729 49.51 2.91 |__netdata 06:05:29 PM - 3730 0.97 0.00 |__netdata 06:05:29 PM - 3733 0.97 0.00 |__netdata 06:05:29 PM - 3738 0.97 87.38 |__netdata 06:05:29 PM - 3740 1.94 0.00 |__netdata 06:05:29 PM - 3743 0.97 0.00 |__netdata 06:05:29 PM - 3744 0.97 0.00 |__netdata 06:05:29 PM - 3745 0.97 0.00 |__netdata 06:05:29 PM - 3751 0.97 0.00 |__netdata 06:05:29 PM 3748 - 0.97 0.00 python 06:05:29 PM - 3748 0.97 0.00 |__python 06:05:29 PM - 4020 3.88 6.80 |__python 06:05:29 PM - 4021 3.88 2.91 |__python 06:05:29 PM 7109 - 0.97 52.43 bash 06:05:29 PM - 7109 0.97 52.43 |__bash 06:05:29 PM 9337 - 1.94 0.00 showq 06:05:29 PM - 9337 1.94 0.00 |__showq 06:05:29 PM - 10406 18642.72 45331.07 |__sysbench 06:05:29 PM - 10407 20953.40 42127.18 |__sysbench 06:05:29 PM - 10408 17404.85 44594.17 |__sysbench 06:05:29 PM - 10409 18404.85 45963.11 |__sysbench 06:05:29 PM - 10410 12807.77 61773.79 |__sysbench 06:05:29 PM - 10411 19445.63 38708.74 |__sysbench 06:05:29 PM - 10412 17883.50 40695.15 |__sysbench 06:05:29 PM - 10413 17189.32 49639.81 |__sysbench 06:05:29 PM - 10414 18169.90 45739.81 |__sysbench 06:05:29 PM - 10415 14832.04 47845.63 |__sysbench 06:05:29 PM 10428 - 0.97 96.12 pidstat 06:05:29 PM - 10428 0.97 96.12 |__pidstat 06:05:29 PM - 21200 1.94 0.00 |__grafana-server 06:05:29 PM - 21202 0.97 0.00 |__grafana-server 06:05:29 PM - 21206 1.94 0.00 |__grafana-server 06:05:29 PM - 21209 0.97 0.00 |__grafana-server 06:05:29 PM - 25021 1.94 0.00 |__grafana-server 06:05:29 PM 29194 - 0.97 150.49 apps.plugin 06:05:29 PM - 29194 0.97 150.49 |__apps.plugin
可以看到sysbench進程的上下文切換看起來並不多，但是sysbench的子線程的上下文切換次數卻很多，我們發現進程的上下文切換發生很多同時中斷次數也上升到將近2萬，具體是什么類型的中斷上升還需要繼續進行監測。
由於中斷發生在內核態，而pidstat只是一個進程的性能分析工具，因此他並不能提供任何關於中斷的詳細信息。因此需要從/proc/interrupts這個只讀文件中讀取。/proc實際上是Linux的一個虛擬文件系統，用於內核空間與用戶空間之間的通信。/proc/interrupts就是這種通信機制的一部分，提供了一個只讀的中斷使用情況。
[root@localhost ~]# watch -d cat /proc/interrupts [root@localhost ~]# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 117486 0 0 0 IO-APIC-edge timer 1: 7 0 0 1 IO-APIC-edge i8042 7: 0 0 0 0 IO-APIC-edge parport0 8: 1 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 108 1 0 0 IO-APIC-edge i8042 14: 0 0 0 0 IO-APIC-edge ata_piix 15: 13 17 19 27 IO-APIC-edge ata_piix 17: 3128770 3092486 3307137 3143451 IO-APIC-fasteoi ioc0 24: 0 0 0 0 PCI-MSI-edge pciehp 25: 0 0 0 0 PCI-MSI-edge pciehp 26: 0 0 0 0 PCI-MSI-edge pciehp 27: 0 0 0 0 PCI-MSI-edge pciehp 28: 0 0 0 0 PCI-MSI-edge pciehp 29: 0 0 0 0 PCI-MSI-edge pciehp 30: 0 0 0 0 PCI-MSI-edge pciehp 31: 0 0 0 0 PCI-MSI-edge pciehp 32: 0 0 0 0 PCI-MSI-edge pciehp 33: 0 0 0 0 PCI-MSI-edge pciehp 34: 0 0 0 0 PCI-MSI-edge pciehp 35: 0 0 0 0 PCI-MSI-edge pciehp 36: 0 0 0 0 PCI-MSI-edge pciehp 37: 0 0 0 0 PCI-MSI-edge pciehp 38: 0 0 0 0 PCI-MSI-edge pciehp 39: 0 0 0 0 PCI-MSI-edge pciehp 40: 0 0 0 0 PCI-MSI-edge pciehp 41: 0 0 0 0 PCI-MSI-edge pciehp 42: 0 0 0 0 PCI-MSI-edge pciehp 43: 0 0 0 0 PCI-MSI-edge pciehp 44: 0 0 0 0 PCI-MSI-edge pciehp 45: 0 0 0 0 PCI-MSI-edge pciehp 46: 0 0 0 0 PCI-MSI-edge pciehp 47: 0 0 0 0 PCI-MSI-edge pciehp 48: 0 0 0 0 PCI-MSI-edge pciehp 49: 0 0 0 0 PCI-MSI-edge pciehp 50: 0 0 0 0 PCI-MSI-edge pciehp 51: 0 0 0 0 PCI-MSI-edge pciehp 52: 0 0 0 0 PCI-MSI-edge pciehp 53: 0 0 0 0 PCI-MSI-edge pciehp 54: 0 0 0 0 PCI-MSI-edge pciehp 55: 0 0 0 0 PCI-MSI-edge pciehp 56: 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-4 NMI: 0 0 0 0 Non-maskable interrupts LOC: 3073899782 2932109969 2836889656 2806862212 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 18 16 18 15 IRQ work interrupts RES: 486603569 505967773 471350449 492621309 Rescheduling interrupts CAL: 75258 1646 73324 1735 Function call interrupts TLB: 33950017 55405448 32837754 52628068 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 117332 117332 117332 117332 Machine check polls ERR: 0 MIS: 0
通過觀察發現，變化速度最快的是重調度中斷RES，這個中斷類型表示，喚醒空閑狀態的CPU來調度薪的任務運行，這是多處理器系統中，調度器用來分散任務導不同CPU的機制，通常也被稱為處理器間中斷
所以，這里的中斷升高還是因為過多任務的調度問題，跟前面上下文切換次數的分析結果是一致的。
上下文切換正常的數值取決於系統本身的CPU性能。如果系統的上下文切換次數比較穩定，那么從數百到1萬以內，都應該算是正常。當上下文切換次數超過一萬次，或者切換次數出現數量級的增長時，就很有可能出現了性能問題。
這個時候需要依據上下文切換的類型，在做具體分析：
-
自願上下文切換變多了，說明進程都在等待自願，有可能發生了IO等其他問題；
-
非自願上下文切換變多了，說明進程都在被強制調度，也就是都在爭搶CPU，說明CPU的確成了瓶頸；
-
中斷次數變多了，說明CPU被中斷處理程序占用了，還需要通過查看/proc/interrupts文件來分析具體的中斷類型
CPU使用率
Linux作為一個多任務操作系統，將每個CPU的時間划分為很短的時間片，再通過調度器輪流分配給各個任務使用，因此造成多任務同時運行的錯覺。
為了維護CPU時間，Linux通過事先定義的節拍率(內核中表示為HZ)，觸發時間中斷，並使用全局變量Jiffies記錄了開機以來的節拍數。每發生一次時間中斷，Jiffies的值就加1。
節拍率HZ是內核的可配選項，可以配置為100、250、1000等。不同的系統可能設置不同的數值，可以通過查詢/boot/config內核選項來查看它的配置(CONFIG_HZ=1000)。比如在我的服務器系統中，節拍率設置成了1000，也就是每秒鍾觸發1000次時間中斷。
[root@localhost ~]# grep 'CONFIG_HZ=' /boot/config-2.6.32-431.el6.x86_64 CONFIG_HZ=1000
正因為節拍率HZ是內核選項，所以用戶空間程序並不能直接訪問。為了方便用戶空間程序，內核還提供了一個用戶空間節拍率USER_HZ，它總是固定為100，也就是1/100秒。這樣，用戶空間程序並不需要關心內核中HZ被設置成了多少，因為它看到的總是固定值USER_HZ。
Linux通過/proc虛擬文件系統，向用戶空間提供了系統內部狀態的信息，而/proc/stat提供的就是系統的CPU和任務統計信息。如果只需要關注CPU，可以執行如下命令：
[root@localhost ~]# cat /proc/stat |grep ^cpu cpu 182993898 729 117810616 13772680802 1631791 13585 2713967 0 0 cpu0 44712915 43 27980485 3442961333 378691 3216 649777 0 0 cpu1 45582701 297 30219438 3442511274 419280 3848 738211 0 0 cpu2 46830450 48 28005111 3445732783 420358 3273 676506 0 0 cpu3 45867831 339 31605580 3441475411 413462 3246 649470 0 0
這里輸出結果是一個表格。其中，第一列表示的是CPU編號，如cpu0、cpu1、cpu2、cpu3，而第一行沒有編號的cpu，表示的是所有CPU的累加。而其他列表示不同場景下CPU的累加節拍數，她的單位是USER_HZ，也就是10ms(1/100秒)，所以這其實就是不同場景下的CPU時間。
-
user(通常縮寫為us)，代表用戶態CPU時間。注意，它不包含下面的nice時間，但包括了gust時間。
-
nice(通常縮寫為ni)，代表低級優先級用戶態CPU時間，也就是進程的nice值被調整為1-19之間的CPU時間，這里注意nice可取值范圍是-20到19，數值越大，優先級反而越低。
-
system(通常縮寫為sys)，代表內核態CPU時間。
-
idle(通常縮寫為id)，代表空閑時間。注意，它不包括等待IO的時間(iowait)。
-
iowait(通常縮寫為wa)，代表等待IO的CPU時間。
-
irq(通常縮寫為hi)，代表處理硬中斷的CPU時間。
-
softirq(通常縮寫為si)，代表處理軟中斷的CPU時間。
-
steal(通常縮寫為st)，代表當系統運行在虛擬機中的時候，被其他虛擬機占用的CPU時間。
-
guest(通常縮寫為guest)，代表通過虛擬化運行其他操作系統的時間，也就是運行虛擬機的CPU時間、
-
guest_nice（通常縮寫為gnice），代表低優先級運行虛擬機的時間。
通常所說的CPU使用率，就是除了空閑時間外的其他時間占用CPU時間的百分比，用公式表示就是
根據這個公式，我們就可以從/proc/stat中的數據，很容易地計算出CPU使用率。當然，也可以用每一個場景的CPU時間，除以總的CPU時間，計算出每個場景的CPU使用率。
查看/proc/stat中的數據，顯示的是開機以來的節拍數累加值，所以直接算出來的，是開機以來的平均CPU使用率，一般沒有什么參考價值。
事實上，為了計算CPU使用率，性能工具一般都會間隔一段時間的兩次值，作差后，再計算出這段時間內平均CPU使用率。
這個公式，就是我們用各種性能工具所看到的CPU使用率的實際計算方法。
進程的CPU使用率方法與系統指標類似，Linux也給每個進程提供了運行情況的統計信息，也就是/proc/[pid]/stat。不過，這個文件包含的數據就比較豐富了，總共有52列的數據。
性能分析工具給出的都是間隔一段時間的平均CPU使用率，所以要注意間隔時間的設置，特別是用多個工具對比分析時，你一定要保證他們用的是相同的間隔時間。
比如，對比一下top和ps這兩個工具報告的CPU使用率，默認的結果很可能不一樣，因為top默認使用3秒時間間隔，而ps使用的卻是進程的整個生命周期。
查看CPU使用率
top和ps是最常用的性能分析工具：
-
top顯示了系統總體的CPU和內存使用情況，以及各個進程的資源使用情況。
-
ps則只顯示了每個進程的資源使用情況。
關於top命令使用見下圖詳解
top命令每個進程都有一個%CPU列，表示進程的CPU使用率。它是用戶態和內核態CPU使用率的總和，包括進程用戶空間使用的CPU、通過系統調用執行的內核空間CPU、以及在就緒隊列等待運行的CPU。在虛擬化環境中，它還包括了運行虛擬機占用的CPU，可以發現top命令並沒有細分進程的用戶態CPU和內核態CPU。
如果想要查看進程CPU使用率的具體情況需要使用pidstat命令來進行觀測；
[root@localhost ~]# pidstat 1 5 Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 04/30/2020 _x86_64_ (4 CPU) 02:29:12 PM PID %usr %system %guest %CPU CPU Command 02:29:13 PM 14734 0.00 0.98 0.00 0.98 3 apps.plugin 02:29:13 PM 29918 0.98 0.98 0.00 1.96 1 pidstat 02:29:13 PM PID %usr %system %guest %CPU CPU Command 02:29:14 PM 3360 0.00 1.00 0.00 1.00 0 redis-server 02:29:14 PM 3723 1.00 0.00 0.00 1.00 0 netdata 02:29:14 PM 14734 1.00 0.00 0.00 1.00 3 apps.plugin 02:29:14 PM 21198 1.00 0.00 0.00 1.00 1 grafana-server 02:29:14 PM 29167 0.00 1.00 0.00 1.00 2 bash 02:29:14 PM 29918 0.00 1.00 0.00 1.00 1 pidstat 02:29:14 PM PID %usr %system %guest %CPU CPU Command 02:29:15 PM 3748 1.00 0.00 0.00 1.00 0 python 02:29:15 PM 14734 0.00 1.00 0.00 1.00 3 apps.plugin 02:29:15 PM 29918 0.00 1.00 0.00 1.00 1 pidstat 02:29:15 PM PID %usr %system %guest %CPU CPU Command 02:29:16 PM 3723 1.00 0.00 0.00 1.00 0 netdata 02:29:16 PM 14734 0.00 1.00 0.00 1.00 3 apps.plugin 02:29:16 PM 21198 0.00 1.00 0.00 1.00 1 grafana-server 02:29:16 PM 29167 1.00 0.00 0.00 1.00 1 bash 02:29:16 PM 29918 1.00 0.00 0.00 1.00 1 pidstat 02:29:16 PM PID %usr %system %guest %CPU CPU Command 02:29:17 PM 3360 1.00 0.00 0.00 1.00 0 redis-server 02:29:17 PM 3723 1.00 1.00 0.00 2.00 0 netdata 02:29:17 PM 14734 1.00 0.00 0.00 1.00 3 apps.plugin 02:29:17 PM 29918 0.00 1.00 0.00 1.00 1 pidstat 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使用率，包括
-
用戶態CPU使用率(%usr)
-
內核態CPU使用率(%system)；
-
運行虛擬機CPU使用率(%guest)；
-
等待CPU使用率(%wait)；
-
以及總的CPU使用率(%CPU)
最后Average部分，還計算了5組數據的平均值。
CPU使用率分析
perf是Linux2.6.31以后內置的性能分析工具，它以性能時間采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。
[root@localhost ~]# perf top Samples: 11K of event 'cpu-clock', Event count (approx.):1015 Overhead Shared Object Symbol 9.42% [kernel] [k] kallsyms_expand_symbol 7.03% perf [.] symbols__insert 6.37% perf [.] rb_next 4.51% [kernel] [k] vsnprintf 4.11% [kernel] [k] format_decode 3.71% [kernel] [k] number 3.45% [kernel] [k] strnlen 2.79% [kernel] [k] string 2.52% perf [.] hex2u64 2.12% libc-2.14.so [.] __strcmp_sse42 1.99% libc-2.14.so [.] __memcpy_sse2 1.86% libc-2.14.so [.] _int_malloc 1.59% libc-2.14.so [.] _IO_getdelim 1.59% libc-2.14.so [.] __strchr_sse42 1.46% libc-2.14.so [.] __libc_calloc 1.33% libc-2.14.so [.] __strstr_sse42 1.19% [kernel] [k] get_task_cred 1.19% [kernel] [k] update_iter 1.06% [kernel] [k] module_get_kallsym 1.06% libpthread-2.14.so [.] pthread_rwlock_rdlock
輸出結果中，第一行包含三個數據，分別是采樣數(Sample)、事件類型(event)和事件總數量(Event count)。例子中，pref總共采集了11K個CPU時鍾事件，需要注意如果采樣數過少，那下面的排序和百分比就沒什么實際參考價值。
-
第一列Overhead，是該符號的性能事情在所有采用中的比例，用百分比來表示。
-
第二列Shared，是該函數或指令所在的動態共享對象，如內核、進程名、動態鏈接庫名、內核模塊名等。
-
第三列Object，是動態共享對象的類型。比如[.]表示用戶空間的可執行程序、或者動態鏈接庫，而[k]則表示內核空間。
-
最后一列Symbol是符號名，也就是函數名。當函數名未知時，用十六進制的地址來表示。
從上面數據，可以看到，占用CPU時鍾最多的是kernel(內核)，不過它的比例也只有9.42%，說明系統並沒有CPU性能問題。
系統進程分析
參考ps命令詳解，這里不再多說
