Linux服務器CPU的一些主要指標說明

http://blog.chinaunix.net/uid-24020646-id-1992006.html

CPU的主要指標:

CPU Utilization

CPU 使用率,CPU的使用時間百分比,75%以上就比較高了。

在任意時間內,CPU有7個狀態: 
1.idle,表示CPU閒置並等待工作分配. 
2.user,表示CPU在運行用戶的進程 
3.system,表示CPU在執行kernel工作 
4.nice,表示CPU花費在被nice改變過優先級的process上的時間(注意:被nice命令改變優先級的process僅指那些nice值爲負的process.花費在被nice命令改變優先級的任務上的時間也將被計算在系統和用戶時間內,因此整個時間加起來可能會超過百分之百) 
5.iowait,表示CPU等待IO操作完成的時間 
6.irq,表示CPU開銷在響應硬中斷上的時間 
7.softirq,表示CPU開銷在響應軟中斷上的時間. 
我們一般用vmstat看到的都是四個狀態:sy,us,id,wa,通過他和load avg結合,基本可以知道cpu的狀態

大部分的性能工具用百分比表示CPU時間.當system時間佔用很高的時候,你可以用"oprofile"工具發現時間都花費在哪裏.當iowait很高的時候,你需要分析你的IO設備,比如磁盤,網卡.

 

Average load

平均負載,上一分鐘同時處於“就緒”狀態的平均進程數。

Load這個東西怎麼理解呢,就像一條馬路,有N個車道,如果N個進程進入車道,那麼正好一人一個,再多一輛車就佔不到車道,要等有一個車空出車道。 
在CPU中可以理解爲CPU可以並行處理的任務數,那麼就是“CPU個數 * 核數”,如果CPU Load = CPU個數 * 核數 那麼就是說CPU正好滿負載,再多一點,可能就要出問題了,有任務不能被及時分配處理器,那麼保證性能的話,最好是小於CPU個數 * 核數 *0.7。


Load Average是 CPU的 Load,它所包含的信息是在一段時間內 CPU正在處理以及等待 CPU處理的進程數之和的統計信息,也就是 CPU使用隊列的長度的統計信息。

Load Average 的值應該小於“CPU個數 * 核數 *0.7 ” ,否則就高了。

比如: 
1個1核CPU,Load Average < 1 * 1 * 0.7 = 0.7; 
1個4核的CPU,Load Average必須 < 1 * 4 * 0.7 = 2.8。 
查看cpu的信息:grep 'model name' /proc/cpuinfo

使用 vmstat 看到的數據中也有這個數據,vmstat 查看r(Load Average)。

image

另外,top命令應該是把每個核的CPU佔用率加起來,算一個和,於是多核情況下會top命令會計算出超過100%。

在linux中,process有兩種狀態: 
1.runnable 
2.blocked waiting for an event to complete 
一個blocked狀態的process可能在等待一個I/O操作獲取的數據,或者是一個系統調用的結果。 
如果一個process在runnable狀態,這就意味着它將同其他runnable狀態的process等待CPU時間,而不是立即獲得CPU時間,一個runnable狀態的process不需要消耗CPU時間,只有當Linux調度進程從runnable隊列中選擇哪個process下次執行。 
當 process在runnable狀態,當時等待CPU時間時,他們形成的等待隊列稱作Run Queue.Run Queue越大,表示等待的隊列越長。 
性能工具通常顯示runnable processes的數目和blocked processes的數目。 
還有一個很常見的系統狀態是load average,系統的load是指running和runnable process的總和。 
例如:如果有兩個processes在running和有三個在等待運行(runnable),那麼系統的load爲五。 
load average是指在指定時間內load的平均值。一般load average顯示的三個數字的時間分別爲1分鐘,五分鐘和十五分鐘。

 

Interrupt rate

每秒內的設備中斷數。CPU接收硬件驅動發出的中斷請求數。

這種中斷通常是下面請看被觸發:

當一個驅動器有一個時間需要被kernel操作時。例如:如果一個磁盤控制器從磁盤上取得了一個數據塊,kernel需要讀取使用這個塊,那麼磁盤控制器會觸發一箇中斷; 
kernel接收每個中斷,一箇中斷處理器運行如果這個中斷被註冊,否則,這個中斷被忽略。 
在系統中,中斷處理器的優先級非常高,而且執行速度非常快。 
很多時候,有些中斷處理並不需要很高的處理優先級,所以也有soft- interrupt handler。

如果有很多的中斷,kernel需要花費大量的時間去處理中斷。

可以檢查/proc/interrupts能夠知道中斷髮生在哪個CPU 上.

 

Interrupt Rate中包括內核由於進程的時間片中斷。 
在 Linux 2.6 中,系統時鐘每 1 毫秒中斷一次時鐘頻率,用 HZ 單位表示(即每秒中斷 1000 次)。 
系統不一樣,內核不一樣的配置100、250的都有。

內核的時鐘頻率可以通過如下命令知道: 

cat /boot/config-`uname -r` | grep '^CONFIG_HZ='

CONFIG_HZ=100

每秒總的時鐘中斷數就是 = cpu個數 * 核數 * CONFIG_HZ

cat /proc/interrupts   可以查看中斷的類型以及次數

          CPU0       CPU1       CPU2       CPU3       
LOC:   97574747   52361843  105207680   69447653   Local timer interrupts 
RES:     107368     257510      98635     186294   Rescheduling interrupts 
CAL:      14174      14206      14164        194   function call interrupts 
TLB:    1007949     853117     992546     591410   TLB shootdowns

用vmstat查看的 in(Interrupt)就是這個參數

image

Context Switch Rate

大部分現在的CPU在同一時間只能運行一個process。 
雖然也有一些CPU,例如超線程技術的CPU,能實現同時運行超過一個process。linux把這種CPU看作多個單線程CPU。 
linux內核不斷的在不同process間切換,造成一個錯覺,讓人感覺一個單CPU同時處理多個任務。 
不同process之間的切換稱作 Context Switch。 
當系統做Context Switch時,CPU保存所有old process的context信息並獲得new process的所有context信息。 
Context信息包括大量的linux追蹤每個process信息,尤其是一些資源: 
那些process正在執行,被分配了哪些內存,它打開了那些文件,等等。 
切換Context會觸發大量的信息移動,這是比較高的開銷。 
如果可能的話儘量保持很小的 context switches。

爲了儘可能的減小context switches,你首先需要知道它們是怎麼產生的。 
首先,kernel調度觸發context switches。爲了保證每個process平等的共享CPU時間,kernel週期性中斷running的process,如果合適, 
kernel調度器會開始一個其他的process而不是讓當前的process繼續執行,每次的週期性中斷或者定時中斷都可能觸發context switch。 
每秒定時中斷的次數因不同架構和不同的kernel版本而不同。 
獲取每秒中斷次數的一個簡單辦法是通過監控 /proc/interrupts文件,看下面的例子: 
root@localhost asm-i386]# cat /proc/interrupts | grep timer; sleep 10 ; cat /proc/interrupts | grep timer 
0: 24060043 XT-PIC timer 
0: 24070093 XT-PIC timer 
上面可以看到在指定的時間內timer次數的變化,每秒產生的中斷次數爲1000次。 
如果你的context switch比timer中斷大很多。那麼context switch更多的可能是I/O請求或者其他長時間的系統調用(比如sleep)產生。 
當一個應用請求一個操作不能立即實現時,kernel開始 context switch操作: 
存入請求的process並且試着切換到其他runnable process。這將使得CPU保持工作狀態.

 

Context Switch大體上由兩個部分組成: 
中斷和進程(包括線程)切換,一次中斷(Interrupt)會引起一次切換,進程(線程)的創建、激活之類的也會引起一次切換。 
Context Switch 的值也和TPS(Transaction Per Second)相關的,假設每次調用會引起N次CS,那麼就可以得出

     Context Switch Rate = Interrupt Rate + TPS* N

CSR減掉IR,就是進程/線程的切換,假如主進程收到請求交給線程處理,線程處理完畢歸還給主進程,這裏就是2次切換。也可以用CSR、IR、TPS的值代入公式中,得出每次事物導致的切換數。因此,要降低CSR,就必須在每個TPS引起的切換上下功夫,只有N這個值降下去,CSR就能降低,理想情況下N=0,但是無論如何如果N >= 4,則要好好檢查檢查。

用vmstat查看 cs(Context Switch)就是這個參數

image

參考資料:

Loadrunner 監控Unix系統性能指標的解釋 
http://blog.csdn.net/marising/archive/2010/01/08/5160210.aspx

壓力測試衡量CPU的三個指標:CPU Utilization、Load Average和Context Switch Rate 
http://blog.csdn.net/marising/archive/2010/01/12/5182771.aspx

LoadRunner壓力測試時監控服務器Linux的資源情況 
http://blog.csdn.net/marising/archive/2010/01/08/5160210.aspx

理解Load Average做好壓力測試 
http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html

CPU負載的分析 
http://www.penglixun.com/tech/system/cpu_load_analyse.html

linux cpu相關性能指標 
http://www.51testing.com/?uid-3787-action-viewspace-itemid-5527

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章