Linux性能優化之CPU

說明：文章有點長，CPU性能主要觀測點的理論知識搬磚堆砌得較多，主要是為了大家對CPU性能主要觀測點有深入理解，這樣才能在性能調優和排錯的過程中把握方向，希望你能耐心讀完。當然，如果你理論基礎扎實也可以跳過。

CPU物理信息

講一個很久以前的笑話，一個老板讓員工買幾臺服務器準備玩玩虛擬化，服務器買回來之后，安裝VMware時卻發現CPU不支持虛擬化，把老板氣的指著那位員工鼻子罵。講這個笑話的目的是想讓大家知道了解服務器硬件特性的重要性。同一時期的市場上，一臺幾千元的服務器和一臺幾萬元的服務器相比較，它們的性能肯定是不一樣的。觀察CPU性能，首先要關注的是一臺服務器上有幾個物理CPU，每個物理CPU有幾個核，每個核有幾個線程數。CPU邏輯核數通常是衡量服務器或虛擬機性能的重要指標。

查看CPU物理匯總信息

執行lscpu命令可以查看CPU物理匯總信息，CPU邏輯核數計算公式如下：

CPU(s)=Socket(s) X Core(s) per socket X Thread(s) per core

CPU(s): 總的邏輯CPU數或線程數

On-line CPU(s) list: 在線的各個邏輯CPU編號

Thread(s) per core: CPU每核的線程數

Core(s) per socket: 每個物理CPU核數

Socket(s): 物理CPU占用的槽位數，有幾個表示有幾顆物理CPU

[root@linuxabc ~]# lscpu

Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit

Byte Order: Little Endian

CPU(s): 4

On-line CPU(s) list: 0-3

Thread(s) per core: 1

Core(s) per socket: 2

Socket(s): 2

NUMA node(s): 1

Vendor ID: GenuineIntel

CPU family: 6

Model: 61

Model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz

Stepping: 4

CPU MHz: 2593.997

BogoMIPS: 5187.99

Hypervisor vendor: VMware

Virtualization type: full

L1d cache: 32K

L1i cache: 32K

L2 cache: 256K

L3 cache: 4096K

NUMA node0 CPU(s): 0-3

Flags: fpu vme de pse tsc ...

查看CPU邏輯核數

判斷服務器的系統負載是否正常，需要參考CPU的邏輯核數，不能簡單地認為只要系統負載的數值大于1就是系統負載高。

在線的CPU邏輯核數：

[root@linuxabc ~]# nproc

4

CPU邏輯核數：

[root@linuxabc ~]# nproc --all

4

查看CPU詳細信息

下面兩個命令可以查看CPU的詳細信息，沒有把命令執行結果粘貼出來是因為命令輸出內容太多。dmidecode命令大家肯定不會陌生，不加任何參數將會顯示服務器的所有硬件信息，我們通常用這個命令來查看服務器的具體型號和序列號，通過序列號可以在服務器廠家的官網查看是否在保。

[root@linuxabc ~]# cat /proc/cpuinfo

[root@linuxabc ~]# dmidecode -t processor

CPU性能主要觀測點

運行隊列統計

一個進程要么是可運行的，要么是阻塞的(正在等待一個事件的完成)。阻塞進程可能正在等待I/O設備的數據，或者是系統調用的結果。如果進程是可運行的，那就意味著它要和其它也是可運行的進程競爭CPU時間。一個可運行的進程不一定會使用CPU，但是當Linux進程調度器決定下一個要運行的進程時，它會從可運行進程隊列中挑選。如果進程是可運行的，同時又在等待使用處理器，這些進程就構成了運行隊列，運行隊列越長，處于等待狀態的進程就越多。

性能工具通常會給出可運行的進程個數和等待I/O的阻塞進程個數。另一種常見的系統統計是平均負載，系統的負載是指正在運行的和可運行的進程總數。比如，如果正在運行的進程為1個，而可運行的進程為2個，那么系統負載就是3，平均負載是給定時間內的負載量。Linux系統取平均負載時間為1分鐘，5分鐘和15分鐘。從而觀察到負載是如何隨時間變化。

上下文切換

Linux是一個多任務操作系統，它支持遠大于CPU數量的任務同時運行。當然，這些任務實際上并不是真的在同時運行，而是因為系統在很短的時間內，將CPU輪流分配給它們，造成多任務同時運行的錯覺。在每個任務運行前，CPU都需要知道任務從哪里加載，又從哪里開始運行，也就是說需要系統事先幫它設置好CPU寄存器和程序計數器(Program Counter, PC)。CPU寄存器是CPU內置的容量小，但速度極快的內存。而程序計數器，則是用來存儲CPU正在執行的指令位置，或者即將執行的下一條指令位置。它們都是CPU在執行任何任務前必須得依賴環境，因此也被叫做CPU上下文。而這些保存下來的上下文，會存儲在內核空間中，并在任務重新調度執行時再次加載進來。這樣就能保證任務原來的狀態不受影響，讓任務看起來還是連續運行。

根據任務的不同，CPU的上下文切換可以可分為三種不同的場景：

（1）進程上下文切換

Linux系統按照特權等級，把進程的運行空間分為內核空間和用戶空間，如下圖所示：

內核空間(Ring 0)具有最高權限，可以直接訪問所有資源。

用戶空間(Ring 3)只能訪問受限資源，不能直接訪問內存等硬件設備，必須通過系統調用訪問內核空間，才能訪問這些特權資源。

換個角度看，也就是說，進程既可以在用戶空間運行，又可以在內核空間中運行。進程在用戶空間運行時，被稱為進程的用戶態，而陷入到內核空間的時候，被稱為進程的內核態。

從用戶態到內核態的轉變，需要通過系統調用來完成。比如，當我們查看文件內容時，就需要多次系統調用來完成：首先調用 open() 打開文件，然后調用 read() 讀取文件內容，并調用 write() 將內容寫到標準輸出，最后再調用 close() 關閉文件。

系統調用的過程有沒有發生CPU上下文的切換呢？答案自然是肯定的。

CPU寄存器里原來用戶態的指令位置，需要先保存起來。接著，為了執行內核態代碼，CPU寄存器需要更新為內核態指令的新位置。最后才是跳轉到內核態運行內核任務。而系統調用結束后，CPU寄存器需要恢復原來用戶保存的狀態，然后再切換到用戶空間，繼續運行進程。所以，一次系統調用的過程，其實是發生了兩次CPU 上下文切換。不過，需要注意的是，系統調用過程中，并不會涉及到虛擬內存等進程用戶態的資源，也不會切換進程。這跟我們通常所說的進程上下文切換是不一樣的。

進程上下文切換，是指從一個進程切換到另一個進程運行，而系統調用過程中一直是在同一個進程中在運行。所以，系統調用過程通常稱為特權模式切換，而不是上下文切換。但實際上，系統調用過程中，CPU 的上下文切換還是無法避免的。那么，進程上下文切換跟系統調用又有什么區別呢?

進程是由內核來管理和調度的，進程的切換只能發生在內核態。所以進程的上下文不僅包括了虛擬內存、棧、全局變量等用戶空間的資源，還包括了內核堆棧、寄存器等內核空間的狀態。因此，進程的上下文切換就比系統調用時多了一步，在保存當前進程的內核狀態和CPU寄存器之前，需要先把該進程的虛擬內存、棧等保存下來，而加載了下一進程的內核態后，還需要刷新進程的虛擬內存和用戶棧。

如下圖所示，保存上下文和恢復上下文的過程并不是“免費”的，需要內核在CPU 上運行才能完成。

根據測試報告，每次上下文切換都需要幾十納秒到數微秒的CPU時間。這個時間還是相當可觀的，特別是在進程上下文切換次數較多的情況下，很容易導致CPU將大量時間耗費在寄存器、內核棧以及虛擬內存等資源的保存和恢復上，進而大大縮短了真正進程運行的時間。這也是導致平均負載升高的一個重要因素。在什么時候進程上下文會進行切換呢？

進程切換時(或者說進程調度時)才需要切換上下文，系統為每個CPU都維護了一個就緒隊列，將活躍進程(即正在運行和正在等待CPU的進程)按照優先級和等待CPU的時間排序，然后選擇最需要CPU的進程，也就是優先級最高和等待CPU時間最長的進程來運行。

進程在什么時候才會被調度到CPU上運行呢？最容易想到的一個時機，就是當進程執行完終止了，它之前使用的CPU會釋放出來，這個時候再從就緒隊列里，取一個新的進程過來運行。其實還有很多其它場景，也會觸發進程調度。

場景一，為了保證所有進程可以得到公平調度，CPU時間被劃分為一段段的時間片，這些時間片再被輪流分配給各個進程。這樣，當某個進程的時間片耗盡了，就會被系統掛起，切換到其它正在等待CPU的進程運行。

場景二，進程在系統資源不足，比如內存不足時，要等到資源滿足后才可以運行，這個時候進程也會被掛起，并由系統調度其他進程運行。

場景三，當進程通過睡眠函數sleep這樣的方法將自己主動掛起時，自然也會重新調度。

場景四，當有優先級更高的進程運行時，為了保證高優先級進程的運行，當前進程會被掛起，由高優先級進程來運行。

最后一個，發生硬件中斷時，CPU上的進程會被中斷掛起，轉而執行內核中的中斷服務程序。

了解這幾個場景是非常有必要的，因為一旦出現上下文切換的性能問題，它們就是幕后兇手。

（2）線程上下文切換

線程與進程最大的區別在于線程是調度的基本單位，而進程則是資源擁有的基本單位。所謂內核中的任務調度，實際上的調度對象是線程，而進程只是給線程提供了虛擬內存、全局變量等資源。所以對于線程和進程，我們可以這么理解：

當進程只有一個線程時，可以認為進程就等于線程。

當進程擁有多個線程時，這些線程會共享相同的虛擬內存和全局變量等資源。這些資源在上下文切換時是不需要修改的。

另外，線程也有自己的私有數據，比如棧和寄存器等，這些在上下文切換時也是需要保存的。

線程的上下文切換可以分為兩種情況：

情況一，前后兩個線程屬于不同進程。此時，因為資源不共享，所以切換過程就跟進程上下文切換是一樣。

情況二，前后兩個線程屬于同一個進程。此時，因為虛擬內存是共享的，所以在切換時，虛擬內存這些資源就保持不動，只需要切換線程的私有數據、寄存器等不共享的數據。

同為上下文切換，但同進程內的線程切換，要比多進程間的切換消耗更少的資源，這正是多線程代替多進程的優勢之一。

（3）中斷上下文切換

為了快速響應硬件的事件，中斷處理會打斷進程的正常調度和執行，轉而調用中斷處理程序，響應設備事件。而在打斷其他進程時，就需要將進程當前的狀態保存下來，這樣在中斷結束后，進程仍然可以從原來的狀態恢復運行。

對同一個CPU來說，中斷處理比進程擁有更高的優先級，所以中斷上下文切換并不會與進程上下文切換同時發生。同樣道理，由于中斷會打斷正常進程的調度和執行，所以大部分中斷處理程序都短小精悍，以便盡可能快地執行結束。

另外，跟進程上下文切換一樣，中斷上下文切換也需要消耗CPU，切換次數過多也會耗費大量的CPU，甚至嚴重降低系統的整體性能。所以，當你發現中斷次數過多時，就需要注意去排查它是否會給你的系統帶來嚴重的性能問題。

為了保證公平地給每個進程分配處理器時間，內核周期性地中斷正在運行的進程，在適當的情況下，內核調度器會決定開始另一個進程，而不是讓當前進程繼續執行。每次這種周期性中斷或決定發生時，系統都可能進行上下文切換。每秒定時中斷的次數和物理架構和內核版本有關。一個檢查中斷頻率的簡單方法是查看/proc/interrupts文件，它可以確定已知時長內發生的中斷次數。

中斷

中斷是指由于CPU接收到外圍硬件(相對于CPU與內存而言)的異步信號或者來自軟件的同步信號而進行相應的硬/軟件處理。

硬中斷：外圍硬件發給CPU或者內存的異步信號就是硬中斷信號。簡言之，外設對CPU的中斷。

軟中斷：由軟件本身發給操作系統內核的中斷信號，稱之為軟中斷。通常是由硬中斷處理程序或進程調度程序對操作系統內核的中斷，也就是我們常說的系統調用。

硬中斷與軟中斷之區別與聯系：

硬中斷是有外設硬件發出的，需要有中斷控制器參與。其過程是外設偵測到變化，告知中斷控制器，中斷控制器通過CPU或內存的中斷腳通知CPU，然后硬件進行程序計數器及堆棧寄存器之現場保存工作，這會引發上下文切換，并根據中斷向量調用硬中斷處理程序進行中斷處理。

軟中斷則通常是由硬中斷處理程序或者進程調度程序等軟件程序發出的中斷信號，無需中斷控制器參與，直接以一個CPU指令形式指示CPU進行程序計數器及堆棧寄存器現場保存工作，這會引發上下文切換，并調用相應的軟中斷處理程序進行中斷處理，即我們通常所言之系統調用。

硬中斷直接以硬件的方式引發，處理速度快。軟中斷以軟件指令之方式適合于對響應速度要求不是特別嚴格的場景。

硬中斷通過設置CPU的屏蔽位可進行屏蔽，軟中斷則由于是指令方式給出，不能屏蔽。

硬中斷發生后，通常會在硬中斷處理程序中調用一個軟中斷來進行后續工作的處理。

硬中斷和軟中斷均會引起上下文切換(進程/線程之切換)，進程切換的過程是差不多的。

CPU周期性地從硬件設備接收中斷，當設備有事件需要內核處理時，就會觸發中斷。比如，如果磁盤控制器剛剛完成從驅動器取數據塊的操作，并準備好提供給內核，那么磁盤控制器就會觸發一個硬中斷。對內核收到的每個中斷，如果已經有響應的已注冊的中斷處理程序，就運行該程序，否則忽略這個中斷。這些中斷處理程序在系統中具有很高的運行優先級，并且通常執行速度也很快。有時，中斷處理程序有工作要做，但是又不需要高優先級，因此它可以啟動軟中斷處理程序。如果有很多中斷，內核會花大量的事件服務這些中斷。查看/proc/interrupts文件可以顯示出哪些CPU上觸發了哪些中斷。

CPU使用率

CPU使用率是個簡單的概念，在任何給定的時間，CPU可以執行以下八件事情中的一個：

CPU可以是空閑的，這意味著處理器實際上沒有做任何工作，并且等待有任務可執行。

CPU可以運行用戶代碼，即指定的“用戶”時間。

CPU可以執行Linux內核中的應用程序代碼，這就是“系統”時間。

CPU可以執行”比較友好“的或者優先級被設置為低于一般進程的用戶代碼。

CPU可以處于I/O等待狀態，即系統正在等待I/O(如磁盤或網絡)完成。

CPU可以處于irq狀態，即它正在用高優先級代碼處理硬件中斷。

CPU可以處于軟irq模式，即系統正在執行同樣由中斷觸發的內核代碼，只不過其運行于較低優先級(下半部代碼)。此情景出現的條件為：發生設備中斷時，而內核在將其移交給用戶空間之前必須對其進行一些處理(比如，處理網絡包)。

管理程序(hypervisor)為另一個虛擬進程提供服務而等待虛擬 CPU 的百分比。

大多數性能工具將這些數值表示為占CPU總時間的百分比，這些時間的范圍從0%到100%，但全部加起來等于100%。一個具有高“系統”百分百的系統表明其大部分時間都消耗在了內核上。像oprofile一樣的工具可以幫助確定時間都消耗在了哪里。具有高“用戶”時間的系統則將其大部分時間都用來運行應用程序。如果系統在應該工作的時候花費了大量的時間處于iowait狀態，那它很可能在等待來自設備的I/O，導致速度變慢的原因可能是磁盤，網卡或其它設備。

CPU性能工具

選擇使用系統性能工具時，通常會使用系統已經默認安裝的工具，使用性能工具通常要注意以下幾個方面：

第一：所選擇的工具最好已經安裝好。在管理比較規范的企業中，在產品環境對服務器的任何人為變動都是要計劃一個時間窗口，準備好變動的步驟，并獲得上級的批準，安裝性能工具也不例外。

第二：所選擇的工具占用系統開銷要小。通常來說系統默認安裝的性能工具所占用的系統開銷都是比較小的，如果你使用了一個新的性能工具，一定要事先測試這個工具在運行時占用的系統資源開銷情況，否則在產品環境使用，可能會因為這個工具占用的系統開銷較大而導致系統資源更加緊張。

第三：對所選擇的工具要非常熟悉。這樣才能更好地分析系統性能，把工具的作用發揮到極致。

下面介紹的有些工具不僅僅可以觀察CPU性能，有的還可以觀察內存和磁盤I/O，本篇文章側重點在CPU性能分析：

top（系統性能匯總）

top命令是查看系統性能時最常用的系統性能工具，它實時地顯示當前系統性能匯總信息。從cpu性能來講，top命令可以觀察到以下幾點：

第一：系統平均負載(Load Average)。

通過觀察系統負載(1分鐘/5分鐘/15分鐘)的平均值，可以判斷系統負載是否正常，經過一定的時間觀察之后，通過對比它們三個的平均值，可以大致判斷系統負載的趨勢。

第二：CPU使用率。

CPU使用率計算公式如下：

us+sy+ni+id+wa+hi+si+st=100%

us：用戶態使用的cpu時間的百分比

sy：系統態使用的cpu時間的百分比

ni：用于nice操作，所占用 CPU 總時間的百分比

id：空閑的cpu時間比

wa：cpu等待磁盤寫入完成時間

hi：硬中斷消耗時間

si：軟中斷消耗時間

st：虛擬機偷取時間

通過觀察上面各個選項的百分比，可以給我們指出排查CPU性能瓶頸問題的大致方向。如果wa比較高，通常意味著磁盤的讀寫性能問題。如果hi比較高，可能與系統硬中斷有關，如果us比較高，應該是用戶程序導致CPU性能問題。

系統負載和CPU使用率沒有直接關系，系統負載高不一定CPU使用率高，反之，CPU使用率高不一定系統負載高。系統負載和進程運行隊列相關，它是正在運行的和可運行的進程總數；CPU使用率是程序在運行期間實時占用CPU百分比。

系統負載理想值：在長期的生成實踐中，大家以CPU的總邏輯核數(或線程數)和系統負載大小進行對比作為判斷系統負載是否正常的依據，比如，一臺服務器有4個邏輯核，如果系統負載小于4，通常情況下我們認為系統負載是正常的；如果系統負載大于4，系統可能存在潛在的性能問題。

CPU使用率理想值：如果CPU使用率長時間處在60% ~ 80%以上，通常可能存在系統性能瓶頸問題。在生產環境，可能由于業務流量的原因在某個時間段CPU使用率會升高，如果從監控系統發現峰值一直存在，且超過80%，就要考慮擴容了。

第三：占用CPU資源最高的進程。

當CPU使用率或平均負載達到警戒線而觸發告警之后，系統管理員通常首先要做的是查找CPU使用率最高的進程，如果它是系統進程，可能就需要重啟這個進程或進一步排查根本原因。如果是應用進程，就需要及時聯系業務運維人員檢查，在生產實踐中，我們有時發現系統審計守護進程(auditd)和發送郵件守護進程(sendmail&postfix)運行異常導致系統負載較高，重啟之后問題解決。

第四：占用CPU最高的線程。

當需要查看某個進程的每個線程的CPU使用率時，意味著需要更深層次地調查根本原因，通常是程序代碼級別的原因。在給開發部門發郵件之前，我們需要提供充分的證據表明這是應用代碼級別的問題。

top命令選項

-H 表示以線程方式顯示

-p process ID 查看某個進程占用的系統資源狀況，參數后面跟的時進程號

-u username 查看某個用戶占用的系統資源狀況，參數后面跟的時用戶名

-i 不顯示未使用任何CPU的進程

-d delay 統計數據更新的時間間隔

-n interations 退出前的迭代次數。

用法示例

示例一：top命令默認輸出。

從top命令的默認輸出結果，我們可以看到系統負載，CPU使用率和占用CPU最多的進程。

[root@linuxabc ~]# top

示例二：查看占用CPU最多的線程。

通過top命令的默認輸出，我們可以找到占用CPU最多的進程，然后根據下面的命令查看某個進程中占用CPU最多的線程，下面的命令輸出僅僅是命令示例，其實這個進程的線程本身占用CPU很低。

[root@linuxabc ~]# top -Hp 1351

mpstat(多處理器統計）

mpstat命令比較簡單，它展示了隨著時間變化的CPU使用率，如果你有多個CPU，mpstat還能夠把CPU使用率按處理器進行區分，因此你可以發現與其它處理器對比，是否某個處理器的CPU使用率比較高，你也可以選擇想要監控的單個CPU，也可以對所有的CPU進行監控。

運行mpstat命令可以幫助觀察是否所有的CPU使用率是均勻的，如果只有其中一個CPU使用率比較高，通常意味著這是一個問題，我們需要進一步調查是那個進程或線程引起的。通過mpstat命令的各個選項輸出，可以幫助我們確定排查的方向。

mpstat命令格式：

mpstat [-P { cpu | ALL ] [ delay { count } ]

命令選項 -P 可以指定對某個或全部CPU進行監控

dely指定了采樣間隔

count指定了采樣次數

mpstat性能統計信息：

cpu：處理器編號。關鍵字all表示統計數據是作為所有處理器之間的平均值計算的

%user：在用戶級別（應用程序）執行時發生的CPU使用率百分比

%nice：顯示在用戶級別，用于nice操作，所占用 CPU 總時間的百分比

%system：在系統級（內核）執行時發生的CPU使用率百分比。請注意這不包括硬件和軟件中斷所花費的時間

%iowait：CPU等待I/O所花費的時間百分比

%irq：CPU處理硬件中斷所花費的時間百分比

%softirq：CPU因軟件中斷服務所花費的時間百分比

%steal：管理程序(hypervisor)為另一個虛擬進程提供服務而等待虛擬 CPU 的百分比

%guest：CPU運行虛擬處理器所花費的時間百分比

%gnice：CPU運行“niced guest”所花費的時間百分比

%idle：CPU空閑且系統沒有磁盤I/O請求的時間百分比

用法示例

示例一：顯示每隔1秒鐘刷新3次的所有CPU性能統計信息。

[root@linuxabc ~]# mpstat -P ALL 1 3

示例二：顯示每隔1秒鐘刷新5次的CPU編號為0的性能統計信息。

[root@linuxabc ~]# mpstat -P 0 1 5

vmstat（虛擬內存統計）

vmstat提供了一個低開銷的良好系統性能視圖。是在系統負載非常高的服務器上觀察系統性能的好工具。vmstat有兩種運行模式，分別是采樣模式和平均模式，如果不指定參數，則vmstat統計工作于平均模式，vmstat顯示從系統啟動以來所有統計數據的均值。如果指定了延遲，第一個采樣仍然是系統啟動以來的均值，之后vmstat按延遲秒數采樣系統并顯示系統統計信息。

vmstat指的是虛擬內存統計，但它不僅能統計系統的虛擬內存性能信息，還能獲取整個系統性能的總體信息，與CPU相關的包括：

正在運行的進程個數

CPU的使用情況

CPU接收中斷次數

調度器執行的上下文切換次數

vmstat命令格式：

vmstat [ -n [ -s ] [ delay [ count ] ]

命令選項：

-n 默認情況下，vmstat定期顯示每個性能統計數據的列標題。本選項禁止該特性，因此初始列標題之后，只顯示性能數據。

-s 本選項一次性輸出vmstat收集的系統統計的詳細信息。該信息為系統啟動后的總數據

delay 延遲秒數，采樣的間隔時間

count 采樣次數

CPU性能統計信息：

vmstat命令提供的各種統計輸出信息，讓我們能跟蹤系統性能的不同方面，在這里只解釋用CPU性能相關的輸出。

r: 當前可運行的進程數。這些進程沒有等待I/O，而是已經準備好運行。理想狀態下，可運行的進程數應與可用CPU的數量相等。

b:等待I/O完成的被阻塞進程數。

forks:創建新進程的次數。

in: 系統發生中斷的次數。

cs: 系統發生上下文切換的次數。

us: 用戶進程消耗的總CPU時間的百分比（包括“nice"時間）

sy: 系統代碼消耗的總CPU時間的百分比，其中包括消耗在系統，硬中斷和軟中斷的時間。

wa: 等待I/O消耗的總CPU時間的百分比

id：系統空閑時間的總cpu時間的百分比

用法示例

示例一：vmstat默認輸出。

如果vmstat運行時沒有使用命令行參數，顯示的將是自系統啟動后它記錄下的統計信息的均值。通過觀察"CPU“列下面的us,sy,sa和id對應的值，可以判斷CPU的工作狀態，下面的示例告訴我們CPU基本處于空閑狀態。

[root@linuxabc ~]# vmstat

示例二：vmstat工作于采樣模式。

vmstat是一個記錄系統在一定負載或測試條件下行為的好工具，這樣就能夠用于查看系統對負載和各種系統事件是如何反應的。在下面的例子中，在in列和cs列能分別看到中斷和上線文切換的次數。上下文切換的數量小于中斷的數量。調度器切換進程的次數少于定時器中斷觸發的次數。這很可能是因為系統級別上是空閑的，在定時器中斷觸發的大多數時候，調度器沒有任何工作要做，因此它不需要從空閑進程切換出去。

[root@linuxabc ~]# vmstat 1 10

示例三：一次性輸出vmstat收集的系統統計的詳細信息。

在下面的vmstat命令輸出中，我們可以看到有一組和”CPU ticks“相關的統計數據，它顯示了全部的CPU ticks的分布情況。”CPU ticks"顯示的是自系統啟動的cpu時間，這里的“tick"是一個時間單位。另外，我們還可以看到中斷和上下文切換的總數，forks也值得我們注意，它表示的是從系統啟動開始，已經創建的新進程的數量。

[root@linuxabc ~]# vmstat -s

sar（系統活動報告）

sar使用低開銷的，記錄系統執行情況信息的方法，r將收集到的系統性能數據記錄到二進制文件。sar既可以顯示當前系統的實時信息，也可以回訪之前收集的歷史信息。

sar能把不同類型的時間戳系統數據保存到日志文件，以便日后檢索和審查。當試圖找出特定服務器在特定時間出現故障的原因時，這個特性是sar最大的亮點。

sar命令格式：

sar [ options ] [ delay [ mount ] ]

命令選項：

-P { cpu | ALL }

-q 報告機器的運行隊列長度和平均負載

-u 報告系統的CPU使用情況（該項為默認輸出）

-w 報告系統發生的上下文切換次數

-o filename 指定保存性能統計信息的二進制輸出文件名

-f filename 從指定性能統計信息的文件名讀取信息

delay 需要等待的采樣間隔時間

count 記錄的樣本總數

CPU性能統計信息：

CPU： all表示所有CPU

%user：顯示在用戶級別(Application)運行使用CPU總時間的百分比

%nice：顯示在用戶級別，用于nice操作，所占用CPU總時間的百分比

%system：在核心級別(kernel)運行所使用CPU總時間的百分比

%iowait：顯示用于等待I/O操作占用CPU總時間的百分比

%steal：管理程序(hypervisor)為另一個虛擬進程提供服務而等待虛擬CPU的百分比

%idle：顯示 CPU 空閑時間占用CPU總時間的百分比

用法示例

示例一：sar命令默認輸出歷史的CPU性能統計信息。