linux系統效能監控--CPU利用率__linux

    在對系統的方法化分析中，首要且最基本的工具之一常常是對系統的 CPU利用率進行簡單測量。 Linux以及大多數基於 UNIX的作業系統都提供了一條命令來顯示系統的平均負荷(loadaverage) 。

[huangc@V-02-01-00860 ~]$ uptime 11:18:05 up 78 days,  1:17, 11 users,  load average: 0.20, 0.13, 0.12

    具體地講，平均負荷值代表了在 1min、 5min和 15min內可以啟動並執行任務平均數量。可啟動並執行任務包括當前正在啟動並執行任務以及雖然可以運行但正在等待某個處理器閒置任務。本例中的系統只有兩個 CPU，它可以通過查看/proc/cpuinfo的內容來確定

[huangc@V-02-01-00860 ~]$ cat /proc/cpuinfo processor: 0vendor_id: GenuineIntelcpu family: 6model: 62model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHzstepping: 4cpu MHz: 2500.000cache size: 25600 KBphysical id: 0siblings: 2core id: 0cpu cores: 2apicid: 0initial apicid: 0fpu: yesfpu_exception: yescpuid level: 13wp: yesflags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm ida arat xsaveopt pln pts dts fsgsbase smepbogomips: 5000.00clflush size: 64cache_alignment: 64address sizes: 40 bits physical, 48 bits virtualpower management:processor: 1vendor_id: GenuineIntelcpu family: 6model: 62model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHzstepping: 4cpu MHz: 2500.000cache size: 25600 KBphysical id: 0siblings: 2core id: 1cpu cores: 2apicid: 1initial apicid: 1fpu: yesfpu_exception: yescpuid level: 13wp: yesflags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm ida arat xsaveopt pln pts dts fsgsbase smepbogomips: 5000.00clflush size: 64cache_alignment: 64address sizes: 40 bits physical, 48 bits virtualpower management:

    在本例中，對於兩個處理器存在兩項，因此平均情況下，處理器要執行的工作會稍少於它的處理能力。在較高層次上，這意味著機器需要執行的工作少於它的處理能力。注意：若在雙 CPU的機器上 uptime命令顯示的負荷平均值小於 2.00的話，這表明處理器仍擁有額外的空閑周期。在 4個 CPU的機器上如果負荷平均值小於 4.00的話也表明同樣的情況，如此等等。然而，負荷平均值單獨並不能說明全部問題。

    儘管該工具可以檢測CPU獲得了利用情況， 但它並不指明系統正在執行什麼工作以及如此繁忙的原因。如果該系統的使用者回應時間是可接受的，可能沒有任何理由需要更深入地探究系統的運行情況。

    諸如uptime之類的簡單工具常常是使用者試圖對應用各種可覺察的緩慢回應時間加以解釋的捷徑。若系統的平均負荷值表明回應時間可能是由單個(或多個)過載的處理器所引起的，那麼可以使用許多其他工具來縮小負荷起因的範圍。

    為了更深入地探究處理器的使用方式，下面介紹的 3種工具可以提供許多關於CPU利用情況的不同理解： vmstat、 iostat和 top。 這些工具各自關注系統監視的不同方面，但都可獲得關於處理器當前使用方式的不同視圖。特別地，下一個步驟是理解處理器是否將處理時間主要消耗在作業系統(經常稱為核心空間)或應用(經常稱為使用者空間)之中，或者處理器是否處於空閑狀態。如果處理器處於空閑狀態，則理解其閒置原因是所有進一步效能分析的關鍵。有許多原因可以導致處理器空閑。例如，最明顯的原因是某個進程無法運行。 這聽起來或許過於明顯， 但如果工作負載的某個組件(例如特定進程或任務)沒有正在啟動並執行話，則效能可能受到影響。在某些情況下，對組件實施緩衝或後退(fallback)機制可以允許一些應用繼續運行， 儘管吞吐率會降低。 例如， Internet網域名稱服務 (DNS)經常被配置為對 named守護進程或者 off-host服務進行查詢。如果某個網域名稱服務 (DNS)供應商(例如出現在/etc/resolv.conf的第一行 name server語句中)當前沒有運行，則在查詢其他資訊供應商之前可能存在一個逾時周期。對於使用者來說，這可能看起來像是應用中的不定時延遲。對於使用 uptime來監視系統的使用者來說，平均負荷值看起來可能不是很高。然而，在這種情況下，vmstat的輸出可以有助於縮小排查問題的範圍。
一、vmstat     vmstat是一個即時效能監控工具。該工具提供了有助於發現系統異常活動的資料，例如會降低系統效能的過多分頁錯誤或環境切換次數。這些資料的顯示頻率可由使用者指定。vmstat輸出樣本如下所示：

[huangc@V-02-01-00860 ~]$ vmstat 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 3853948 1386860  43092 5049692    1    6     5    34    1    3 27 27 46  0  0

vmstat 提供以下資訊 ： procs部分提供了在產生報告時正在啟動並執行進程數目(r)以及被阻塞的進程數目(b)。可以利用這些資訊來檢查運行中以及阻塞進程的數目是否與預期值相符。如果與預期不符的話，可以檢查：應用和核心的參數、系統調度器和 I/O調度器、進程在可用處理器之間的分布等。 memory部分提供了換出記憶體(swpd)、空閑記憶體(free)、 I/O資料結構的緩衝區快取(buff)，以及從磁碟讀取檔案的記憶體緩衝(cache)的容量，單位為 KB。 swpd的取值反映了kswapd的活動情況 。 s wap 部分提供了從磁碟上換入的記憶體容量 (si) 以及換出到磁碟上的記憶體量 (so) ， 單位為 KB/s 。 so 反映了當資料被換出至交換區時 kswapd 的活動情況，而 si 則反映了當頁面被換回到實體記憶體時發生分頁錯誤的情況 。

io 部分提供了從裝置讀入的塊數 (bi) 以及寫出到裝置上的塊數 (bo) ，單位為 KB/s 。當運行 I/O 密集的應用時，應特別注意這兩個部分的值 。 system 部分提供了每秒的中斷數目 (in) 和環境切換數目 (cs) 。
cpu 部分提供了使用者 (us) 、 系統 (sy) 、 真正空閑 (id) 以及等待 I/O 完成 (wa) 在 CPU 總時間中所佔的百分比。 CPU 利用率也許是最常用的量度。 若 wa 值過大， 則應該檢查 I/O 子系統，例如，可以斷定需要更多的 I/O 控制器和磁碟以便減少 I/O 等待時間。
    注意 uptime 提供了可運行進程數目在 3 個時間範圍 (1min 、 5min 和 15min) 內的另一種視圖。 因此， 如果 uptime 給出的平均負荷值在任何時間範圍內都大於 1 ，則 vmstat 報告的可運行任務數量也應該接近 1 。
    vmstat 能夠以重複的時間間隔定期提供資訊，因此可通過以下命令獲得動態系統檢視表 。

vmstat 5 10

    上述命令的含義是每 5s 輸出 vmstat 資訊， 共執行 10 次。 另外， 若根據 uptime 的輸出結果， 平均負荷值在過去的 1/5/10min 內一直為 1 ， 則該命令的輸出結果通常應該在每個輸出行均顯示一項可啟動並執行任務。 在 vmstat 的輸出資訊中出現峰值為 5 、 7 甚至 20 的情況並不奇怪。因為負荷平均值是一種計算平均值而不是即時快照。這兩個視圖對於系統效能分析工作而言各自有其優點 。
    假設在一個情境中使用者報告某個工作負載的回應時間緩慢。 通過 uptime 檢查負荷平均值的結果表明， 負荷平均值非常低， 甚至可能位於時間基準以下。 另外， vmstat 顯示出可運行任務的數量非常低， 且基於 CPU 空閑時間的百分比可判斷該系統相對空閑。分析人員可能會將這些結果解釋成某個關鍵進程已退出或正在阻塞等待某個未完成的事件。例如，一些應用程式使用某種訊號量技術來指派工作並等待完成。也許工作被指派給一個後端伺服器或其他應用程式，而該應用程式由於某種原因已停止處理所有活動。結果，與使用者最接近的應用程式被阻塞，變為不可運行，並等待著反饋某個完成訊息，然後它才能將資訊返回給使用者。這可能導致系統管理員將注意力集中於伺服器應用以查明為何無法完成針對其排隊的請求 。     在 另一個情境中，假定負荷平均值超過 1 ，甚至可能比已建立的基準平均高出一個百分點。另外， vmstat 顯示總有一兩個進程是可啟動並執行，但在一段擴充的時間範圍內使用者時間的百分比將近 100% 。可能需要其他工具例如 ps(1) 或 top(1) 來發現有哪個或哪些進程正在佔用著 100% 的 CPU 時間。 ps(1) 提供了所有當前存在的進程列表， 或基於命令選項給出選定的進程子集。 top(1)( 或 gtop(1)) 為最活躍的進程提供了持續更新的視圖， 其中最活躍的進程可定義為當前佔用 CPU 時間最多的進程。這些資料可能有助於識別出在系統中沒有執行有效工作的失控進程。 如果 vmstat(1)已報告這些進程主要在使用者空間中運行，則系統管理員可能希望將調試器(例如 gdb(1)) 串連至該進程，並使用斷點、跟蹤執行或其他調試方法來理解該應用當前執行的工作。 如果 vmstat已報告大部分時間都作為“ 系統” 時間而消耗，則可以使用其他工具例如 strace(1) 來確定正在執行哪些系統調用； 若 vmstat(1)報告指出相當大比例的時間都用於等待 I/O操作完成， 則可以使用 sar(1) 等工具來查看正在使用中的裝置，並可能提供一些諸如哪些應用或檔案系統處於使用中、系統是否正在執行交換或頁面調度等資訊 。


二、top與gtop工具
    t op 和 gtop 工具非常有助於對導致產生 vmstat 或 uptime 所顯示的高層資訊的任務和進程加以理解。 它們可以顯示哪些進程是活躍的以及哪些進程消耗的處理時間或記憶體最多。     top 命令對於所有正在啟動並執行進程和系統載荷提供不斷更新的概覽資訊，包括 CPU 負荷、 記憶體使用量以及每個進程的記憶體使用量情況，具體如下面的快照內容所述。注意 top 也提供了負荷平均值的快照，這非常類似於 uptime(1) 的做法；然而， top 也提供了關於被建立但當前正在休眠的進程數量以及正在啟動並執行進程數量的分類匯總資訊。“ 休眠”任務是那些處於被阻塞並等待某項活動的任務， 例如使用者對鍵盤的一次按鍵、來自管道或 socket 的資料、來自另一台主機 ( 例如，等待別人發出內容請求的 Web 伺服器 ) 的請求等。 top(1) 還單獨顯示了每個處理器的負荷平均值， 這有助於識別在調度任務過程中的任何不均衡性。預設狀態下， top 的輸出被經常地重新整理，且把任務基於 CPU 佔用時間的百分比排序。當然也可能存在著其他排序選項，例如 CPU 累加消耗量或者記憶體消耗百分比 。

[huangc@V-02-01-00860 ~]$ toptop - 15:17:44 up 78 days,  5:17, 13 users,  load average: 0.00, 0.10, 0.12Tasks: 227 total,   1 running, 225 sleeping,   1 stopped,   0 zombieCpu(s):  7.8%us, 12.1%sy,  0.0%ni, 79.9%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%stMem:   8193720k total,  6315000k used,  1878720k free,    47436k buffersSwap:  4128760k total,  3852496k used,   276264k free,  5054928k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                       2301 seeproxy  20   0 2196m  13m  660 S 15.5  0.2  15285:39 /home/seeproxy/seeproxy/python27/bin/python /home/seeproxy/seeproxy/seeproxy.p30824 huangc    20   0  872m 1744 1096 S  7.3  0.0  64:05.38 hsserver -f warmstandby_hc.xml -start proxysvr -t ar -s 1 -status 0           32729 zhouds    20   0 1958m  41m  936 S  4.6  0.5  62:54.17 hsserver -f front_demo.xml -start mainsvr -t ar -s 0 -status 0                32740 zhouds    20   0 2818m  35m  736 S  4.6  0.4  71:29.01 /home/zhouds/linux.x64/bin/hsserver -f queue_demo.xml -t ar -s 0 -d /home/zhou 1307 shizj     20   0  144g 335m  800 S  4.0  4.2  60:50.38 hsserver -f shizj_uft.xml -start mainsvr -t ar -s 0 -uft_status 1 -system_type  498 zhouds    20   0 2722m  48m 5920 S  3.3  0.6  46:57.94 hsserver -f uft_demo.xml -start mainsvr -t ar -s 0 -status 0 -system_type 0 -l 1496 shizj     20   0 26.6g  11m 1188 S  3.3  0.1  43:37.45 hsserver -f shizj_init.xml -start mainsvr -t ar -s 0 -status 0                30829 huangc    20   0 1355m  19m  796 S  3.3  0.2  45:27.38 /home/huangc/linux.x64/bin/hsserver -f warmstandby_hc.xml -t ar -s 1 -d /home/ 1303 shizj     20   0 1286m 6120  728 S  2.3  0.1  30:22.74 hsserver -f shizj_arb.xml -start arbsvr -t ar -s 0 -status 0                  32723 zhouds    20   0 1234m  17m  668 S  2.3  0.2  33:27.00 hsserver -f arb_demo.xml -start arbsvr -t ar -s 0 -status 0                   32725 zhouds    20   0  614m  632  392 S  1.6  0.0  17:38.62 hsserver -f queue_demo.xml -start proxysvr -t ar -s 0 -status 0               13284 huangc    20   0 15036 1336  948 R  1.0  0.0   0:00.10 top                                                                            1341 root      20   0 82292 1412 1104 S  0.3  0.0 154:38.71 /usr/sbin/vmtoolsd                                                             1750 root      20   0 13584  288  220 S  0.3  0.0  15:07.26 lldpad -d                                                                         1 root      20   0 19364  312  136 S  0.0  0.0   0:15.99 /sbin/init                                                                        2 root      20   0     0    0    0 S  0.0  0.0   0:00.68 [kthreadd]                                                                        3 root      RT   0     0    0    0 S  0.0  0.0   0:10.29 [migration/0]                                                                     4 root      20   0     0    0    0 S  0.0  0.0  36:04.74 [ksoftirqd/0]                                                                     5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 [migration/0]                                                                 [huangc@V-02-01-00860 ~]$ 

top 的輸出結果中包括以下資訊：
第 1行顯示系統正常已耗用時間，包括目前時間、 系統自從上次重啟後已啟動並執行時間長度、 目前使用者數量， 以及 3個用於表示在先前的 1min、 5min和 15min內準備啟動並執行平均處理器數目的平均負荷值。 第 2行給出進程的統計資訊，包括在 top輸出結果的上次更新之際正在啟動並執行進程總數。 這一行還顯示睡眠中的進程、 運行中的進程、 殭屍進程以及已停止進程的數目。 第 3行和第 4行顯示各個 CPU的統計資訊，包括使用者進程、 系統進程、 niced進程以及空閑進程所佔用的CPU時間百分比。 第 5行提供了記憶體統計資訊，包括記憶體總量、已用記憶體量、空閑記憶體量、不同進程共用的記憶體量，以及用作緩衝區的記憶體量。 第 6行顯示了虛存或交換活動的統計資訊，包括交換空間總量、已用的交換空間大小、閒置交換空間大小以及緩衝的交換空間大小。 其餘各行顯示了具體進程的統計資訊。一些更有用的 top 參數如下所示：
d 輸出資料的更新延遲。 p 只顯示指定進程的資訊。最多可指定 20個進程。 S 顯示進程及其子進程所佔用時間的匯總資訊，還給出進程的停工時間。 I 不報告空閑進程的資訊。 H 顯示進程的所有線程資訊。 N 產生報告的次數。 top 還提供了一種動態模式修改所報告的資訊。按下 F 鍵可以啟用動態模式。再按下 J 鍵， 就可以添加一個新列來顯示某個當前執行的進程最近使用的 CPU 時間。 
三、sar工具     sar 是 sysstat 工具包的組成部分。它收集並報告作業系統中廣泛的系統活動，包括 CPU 利用率、 環境切換和中斷速率、 頁換入和頁換出速率、 共用記憶體使用量情況、 緩衝區使用方式以及網路使用方式。 sar(1) 工具很有用， 它不斷地收集系統活動資訊並將其記
錄到一組記錄檔中， 從而有可能在報告效能衰退事件之前以及在該事件之後評估效能問題。 sar 常常用於確定事件的時間，也可用於標識特定的系統行為變化。 sar 可以使用更短的時間間隔或固定數目的時間間隔來輸出資訊，這非常類似於 vmstat 。基於數量和時間間隔參數的取值， sar 工具以指定的時間間隔 ( 以秒為單位 ) 執行指定次數的資訊輸出操作。另外， sar 可以為所收集的許多資料點提供平均資訊。
1、CPU利用率

[huangc@V-02-01-00860 ~]$ sar -u -P ALL -C 5Linux 2.6.32-431.el6.x86_64 (V-02-01-00860) 10/12/16 _x86_64_(2 CPU)15:50:19        CPU     %user     %nice   %system   %iowait    %steal     %idle15:50:24        all      3.38      0.00      5.28      0.00      0.00     91.3415:50:24          0      3.39      0.00      5.30      0.00      0.00     91.3115:50:24          1      3.36      0.00      5.25      0.00      0.00     91.3915:50:24        CPU     %user     %nice   %system   %iowait    %steal     %idle15:50:29        all      3.17      0.00      4.66      0.00      0.00     92.1715:50:29          0      3.40      0.00      4.25      0.00      0.00     92.3615:50:29          1      2.75      0.00      5.08      0.00      0.00     92.1615:50:29        CPU     %user     %nice   %system   %iowait    %steal     %idle15:50:34        all      2.95      0.00      5.16      0.00      0.00     91.8915:50:34          0      3.36      0.00      5.25      0.00      0.00     91.3915:50:34          1      2.75      0.00      4.86      0.00      0.00     92.39

    網路和磁碟服務進程是耗用 CPU 的系統組件之一。當作業系統產生 I/O 活動時， 相應的裝置子系統會作出響應，並使用硬體中斷訊號來指示 I/O 請求已完成。 作業系統對這些中斷進行計數。 輸出結果有助於可視化呈現網路和磁碟 I/O 活動的速率。 sar(1) 提供了這種輸入。利用效能基準也許可以對系統中斷速率進行跟蹤，這將是作業系統開銷的另一個來源或者系統效能潛在變化的指標。“ -I SUM ” 選項可以產生如下資訊，包括每秒的中斷總次數。“ -I ALL ” 選項可以為每個中斷源提供類似資訊 ( 未顯示 )。
2、中斷速率

10:53:53 INTR intr/s10:53:58 sum 4477.6010:54:03 sum 6422.8010:54:08 sum 6407.2010:54:13 sum 6111.4010:54:18 sum 6095.4010:54:23 sum 6104.8110:54:28 sum 6149.80. . .Average: sum 4416.5

    在 可以通過 sar -A 命令獲得基於 CPU 的中斷分布視圖 ( 以下樣本摘錄自完整的輸出結果 ) 。注意系統的 IRQ 取值為 0 、 1 、 2 、 9 、 12 、 14 、 17 、 18 、 21 、 23 、 24 和 25 。

3、中斷分布     中斷分布的研究可能揭示出中斷處理機制中的不平衡性。下一步需要對調度器進行分析。解決該問題的一種方法是通過為特定裝置的中斷(或 IRQ)設定與某個特定 CPU或一組 CPU相關的親合度，將 IRQ處理綁定到特定的某個處理器或許多處理器上。 例
如，如果 0x0001被回顯到/proc/irq/ID(其中 ID對應於一個裝置)，則只有 CPU 0才處理該裝置的 IRQ；如果 0x000f被回顯到/proc/irq/ID，則 CPU 0～CPU 3將負責處理該裝置的 IRQ。對於某些工作負載而言，這種技術可以減少在繁重使用的特定處理器上發生的競爭現象。這項技術可以更高效地處理 I/O中斷，從而相應地提高 I/O效能 。