Linux System and Performance Monitoring(CPU篇)

時間 2019-11-29

標籤 linux system performance monitoring cpu 欄目 Linux 简体版

原文原文鏈接

1.0 性能監控介紹php

性能優化就是找到系統處理中的瓶頸以及去除這些的過程,多數管理員相信看一些相關的」cook book」就能夠實現性能優化,一般經過對內核的一些配置是能夠簡單的解決問題,但並不適合每一個環境,性能優化實際上是對OS 各子系統達到一種平衡的定義,這些子系統包括了:mysql

CPU
Memory
IO
Networkios

這些子系統之間關係是相互彼此依賴的,任何一個高負載都會致使其餘子系統出現問題.好比:web

大量的頁調入請求致使內存隊列的擁塞
網卡的大吞吐量可能致使更多的 CPU開銷
大量的CPU開銷又會嘗試更多的內存使用請求
大量來自內存的磁盤寫請求可能致使更多的 CPU 以及 IO問題
因此要對一個系統進行優化,查找瓶頸來自哪一個方面是關鍵,雖然看似是某一個子系統出現問題,其實有多是別的子系統致使的.sql

1.1 肯定應用類型數據庫

基於須要理解該從什麼地方來入手優化瓶頸,首先重要的一點,就是理解並分析當前系統的特色,多數系統所跑的應用類型,主要爲2種:apache

IO Bound(譯註:IO 範疇): 在這個範疇中的應用,通常都是高負荷的內存使用以及存儲系統,這實際上表示IO 範疇的應用,就是一個大量數據處理的過程.IO 範疇的應用不對CPU以及網絡發起更多請求(除非相似NAS這樣的網絡存儲硬件).IO 範疇的應用一般使用CPU 資源都是爲了產生IO 請求以及進入到內核調度的sleep 狀態.一般數據庫軟件(譯註:mysql,oracle等)被認爲是IO 範疇的應用類型.性能優化

CPU Bound(譯註:CPU 範疇): 在這個範疇中的應用,通常都是高負荷的CPU 佔用. CPU 範疇的應用,就是一個批量處理CPU 請求以及數學計算的過程.一般web server,mail server,以及其餘類型服務被認爲是CPU 範疇的應用類型.bash

1.2 肯定基準線統計服務器

系統利用率狀況,通常隨管理員經驗以及系統自己用途來決定.惟一要清楚的就是,系統優化但願達成什麼效果,以及哪些方面是須要優化,還有參考值是什麼?所以就創建一個基準線,這個統計數據必須是系統可用性能狀態值,用來比較不可用性能狀態值.

在如下例子中,1個系統性能的基準線快照,用來比較當高負荷時的系統性能快照.

[root @opt-001 ~ ] # vmstat 1 -S m
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 0 91 239 3047 0 0 4 55 32 20 1 1 98 0 0
0 0 0 92 239 3047 0 0 0 0 1127 3131 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1105 3064 0 0 100 0 0
0 0 0 92 239 3047 0 0 4 0 1156 3071 1 1 99 0 0
0 0 0 92 239 3047 0 0 0 604 1177 2976 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1082 3018 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 16 1075 3023 0 0 99 1 0
2 0 0 92 239 3047 0 0 0 56 1101 3134 0 0 100 0 0
0 0 0 92 239 3047 0 0 0 0 1041 3040 0 0 100 0 0

[root @opt-001 ~ ] # vmstat 1 -S m
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 0 710 113 2573 0 0 4 55 0 20 1 1 98 0 0
2 0 0 701 113 2582 0 0 4192 0 1175 4754 24 1 75 1 0
2 0 0 694 113 2590 0 0 3584 21012 1470 4323 16 1 61 22 0
2 0 0 684 113 2598 0 0 4272 572 1167 4813 23 1 75 2 0
3 0 0 676 113 2606 0 0 3832 0 1211 5168 25 1 75 0 0
2 0 0 671 113 2610 0 0 1336 0 1061 4230 24 0 75 0 0
2 0 0 664 113 2618 0 0 2916 0 1168 5368 24 1 74 1 0
2 0 0 658 113 2623 0 0 0 20228 1099 5656 24 1 68 7 0
2 0 0 654 113 2628 0 0 0 0 1048 5275 24 1 75 0 0
2 0 0 649 113 2633 0 0 4 0 1075 5681 25 1 73 0 0
2 0 0 644 113 2638 0 0 0 0 1066 5257 25 1 75 0 0
2 0 0 637 113 2645 0 0 1432 0 1050 5462 24 1 75 1 0
5 0 0 628 113 2654 0 0 4348 24840 1240 5301 23 2 70 6 0

從上面第一個結果可看到,最後一列(id) 表示的是空閒時間,咱們能夠看到,在基準線統計時,CPU 的空閒時間在98% - 100%.在第二個結果可看到,系統處於60%~70%的佔用率。從這個比較中,咱們就能夠肯定是不是CPU 使用率應該被優化.

2.0 安裝監控工具

多數 *nix系統都有一堆標準的監控命令.這些命令從一開始就是*nix 的一部分.Linux 則經過基本安裝包以及額外包提供了其餘監控工具,這些安裝包多數都存在各個Linux 發佈版本中.儘管還有其餘更多的開源以及第三方監控軟件,但本文檔只討論基於Linux 發佈版本的監控工具.

本章將討論哪些工具怎樣來監控系統性能.

Tool	描述	系統自帶	擴展包
vmstat	通用的性能監控工具	yes	yes
mpstat	提供每一個cpu的統計信息	no	yes
sar	通用的性能監控工具	no	yes
iostat	提供磁盤統計	no	yes
netstat	提供網絡統計	yes	yes
dstat	統計監控彙總	no	大多數發行版
iptraf	網絡流量監控	no	yes
netperf	網絡帶寬工具	no	大多數發行版
ethtool	網卡配置顯示工具	yes	yes
iperf	網絡帶寬公積金	no	yes
tcptrace	網絡包分析工具	no	yes

3.0 CPU 介紹

CPU 利用率主要依賴因而什麼資源在試圖存取.內核調度器將負責調度2種資源種類:線程(單一或者多路)和中斷.調度器去定義不一樣資源的不一樣優先權.如下列表從優先級高到低排列:

Interrupts(譯註:中斷) - 設備通知內核,他們完成一次數據處理的過程.例子,當一塊網卡設備遞送網絡數據包或者一塊硬件提供了一次IO 請求.

Kernel(System) Processes(譯註:內核處理過程) - 全部內核處理過程就是控制優先級別.

User Processes(譯註:用戶進程) - 這塊涉及」userland」.全部軟件程序都運行在這個user space.這塊在內核調度機制中處於低優先級.

從上面,咱們能夠看出內核是怎樣管理不一樣資源的.還有幾個關鍵內容須要介紹,如下部分就將介紹context(譯註:上下文切換),run queues(譯註:運行隊列)以及utilization(譯註:利用率).

3.1 上下文切換

多數現代處理器都可以運行一個進程(單一線程)或者線程.多路超線程處理器有能力運行多個線程.然而,Linux 內核仍是把每一個處理器核心的雙核心芯片做爲獨立的處理器.好比,以Linux 內核的系統在一個雙核心處理器上,是報告顯示爲兩個獨立的處理器.

一個標準的Linux 內核能夠運行50 至 50,000 的處理線程.在只有一個CPU時,內核將調度並均衡每一個進程線程.每一個線程都分配一個在處理器中被開銷的時間額度.一個線程要麼就是得到時間額度或已搶先得到一些具備較高優先級(好比硬件中斷),其中較高優先級的線程將從區域從新放置回處理器的隊列中.這種線程的轉換關係就是咱們提到的上下文切換.

每次內核的上下文切換,資源被用於關閉在CPU寄存器中的線程和放置在隊列中.系統中越多的上下文切換,在處理器的調度管理下,內核將獲得更多的工做.

3.2 運行隊列

每一個CPU 都維護一個線程的運行隊列.理論上,調度器應該不斷的運行和執行線程.進程線程不是在sleep 狀態中(譯註:阻塞中和等待IO中)或就是在可運行狀態中.若是CPU 子系統處於高負荷下,那就意味着內核調度將沒法及時響應系統請求.致使結果,可運行狀態進程擁塞在運行隊列裏.當運行隊列愈來愈巨大,進程線程將花費更多的時間獲取被執行.

比較流行的術語就是」load」,它提供當前運行隊列的詳細狀態.系統 load 就是指在CPU 隊列中有多少數目的線程,以及其中當前有多少進程線程數目被執行的組合.若是一個雙核系統執行了2個線程,還有4個在運行隊列中,則 load 應該爲 6. top 這個程序裏顯示的load averages 是指1,5,15 分鐘之內的load 狀況.

3.3 CPU 利用率

CPU 利用率就是定義CPU 使用的百分比.評估系統最重要的一個度量方式就是CPU 的利用率.多數性能監控工具關於CPU 利用率的分類有如下幾種:

User Time(譯註:用戶進程時間) - 關於在user space中被執行進程在CPU 開銷時間百分比.

System Time(譯註:內核線程以及中斷時間) - 關於在kernel space中線程和中斷在CPU 開銷時間百分比.

Wait IO(譯註:IO 請求等待時間) - 全部進程線程被阻塞等待完成一次IO 請求所佔CPU 開銷idle的時間百分比.

Idle(譯註:空閒) - 一個完整空閒狀態的進程在CPU 處理器中開銷的時間百分比.

4.0 CPU 性能監控

理解運行隊列,利用率,上下文切換對怎樣CPU 性能最優化之間的關係.早期說起到,性能是相對於基準線數據的.在一些系統中,一般預期所達到的性能包括:

Run Queues - 每一個處理器應該運行隊列不超過1-3 個線程.例子,一個雙核處理器應該運行隊列不要超過6 個線程.

CPU Utiliation - 若是一個CPU 被充分使用,利用率分類之間均衡的比例應該是
65% - 70% User Time
30% - 35% System Time
0% - 5% Idle Time

Context Switches - 上下文切換的數目直接關係到CPU 的使用率,若是CPU 利用率保持在上述均衡狀態時,大量的上下文切換是正常的.

不少Linux 上的工具能夠獲得這些狀態值,首先就是 vmstat 和 top 這2個工具.

4.1 vmstat 工具的使用

vmstat 工具提供了一種低開銷的系統性能觀察方式.由於 vmstat 自己就是低開銷工具,在很是高負荷的服務器上,你須要查看並監控系統的健康狀況,在控制窗口仍是可以使用vmstat 輸出結果.這個工具運行在2種模式下:average 和 sample 模式.sample 模式經過指定間隔時間測量狀態值.這個模式對於理解在持續負荷下的性能表現,頗有幫助.下面就是

vmstat 運行1秒間隔的示例:

[root @opt-001 ~ ] # vmstat 1 -S m
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 0 633 157 2618 0 0 4 54 12 23 1 1 98 0 0
1 0 0 633 157 2618 0 0 0 0 1062 3013 0 0 100 0 0
1 0 0 633 157 2618 0 0 0 0 1039 2924 0 0 100 0 0
1 0 0 633 157 2618 0 0 0 0 1041 3005 0 0 100 0 0

Table 1: The vmstat CPU statistics
Field          Description
r         The amount of threads in the run queue. These are threads that are runnable, but the CPU is not available to execute them.
當前運行隊列中線程的數目.表明線程處於可運行狀態,但CPU 還未能執行.
b          This is the number of processes blocked and waiting on IO requests to finish.
當前進程阻塞並等待IO 請求完成的數目
in          This is the number of interrupts being processed.
當前中斷被處理的數目
cs          This is the number of context switches currently happening on the system.
當前kernel system中,發生上下文切換的數目
us          This is the percentage of user CPU utilization.
CPU 利用率的百分比
sys          This is the percentage of kernel and interrupts utilization.
內核和中斷利用率的百分比
wa         This is the percentage of idle processor time due to the fact that ALL runnable threads are blocked waiting on IO.
全部可運行狀態線程被阻塞在等待IO 請求的百分比
id          This is the percentage of time that the CPU is completely idle.
CPU 空閒時間的百分比

4.2 案例學習:持續的CPU 利用率

在這個例子中,這個系統被充分利用

[root @opt-001 ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
6 0 0 930 62 271 0 0 0 0 17818 35803 5 38 57 0 0
8 0 0 561 62 271 0 0 0 0 17645 34637 4 35 61 0 0
7 0 0 224 62 271 0 0 0 0 17837 32955 5 37 58 0 0
5 0 0 129 62 184 0 0 0 0 17903 29061 3 24 73 0 0
1 0 0 131 58 159 0 0 0 32 17855 21732 1 9 90 0 0
1 0 0 128 58 159 0 0 0 0 17579 18884 1 7 93 0 0
0 0 0 126 58 159 0 0 0 12 17598 18832 1 8 91 0 0
1 1 0 130 55 156 0 0 0 0 17553 18652 1 7 71 22 0

根據觀察值,咱們能夠獲得如下結論:

1,有大量的中斷(in) 和更多的的上下文切換(cs).這意味着一個單一的進程在產生對硬件設備請求的同時發生了不少的上下文切換，這也不奇怪，當系統中裝有多顆CPU或者1CPU多核時這種上下文的切換會更頻繁。

2,進一步顯示某單個應用,user time(us) 常常在10%或者更少.但sy的卻佔了不少的比例，說明內核花了不少的資源來進行上下文切換。能夠得知系統中併發了不少程序。

3,運行隊列中有4次超出了容許的範圍，還有4次在容許的範圍內。這個隊列數應該控制在小於等於CPU核心數量。

4.3 案例學習:超負荷調度

在這個例子中,io等待時間佔用不少比例的例子

[root @monitor ~ ] # vmstat 1 -S m
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 3 53 55 53 1477 0 0 9 216 5 6 2 1 93 4 0
1 2 53 53 54 1474 0 0 92 29820 1195 2954 2 41 8 48 0
0 3 53 27 54 1387 0 0 0 950504 1237 10419 1 43 6 51 0
2 4 53 50 48 1369 0 0 0 123744 1172 297 0 7 0 93 0
0 5 53 50 40 1378 0 0 4 95996 1179 325 0 10 0 90 0
0 5 53 50 18 1400 0 0 0 104108 1150 301 0 9 0 91 0
0 5 53 48 10 1408 0 0 0 131272 1173 345 1 8 0 92 0
0 5 53 51 10 1406 0 0 4 89912 1161 249 0 7 0 94 0
0 5 53 50 9 1405 0 0 0 112952 1146 234 0 10 0 90 0

根據觀察值,咱們能夠獲得如下結論:

1,某些時刻上下文切換數目高於中斷數目,說明kernel中至關數量的時間都開銷在上下文切換線程.

2,大量的上下文切換將致使CPU 利用率分類不均衡.很明顯實際上等待io 請求的百分比(wa)很是高,以及user time百分比很是低(us).

3,由於CPU 都阻塞在IO請求上,因此運行隊列裏也有至關數目的可運行狀態線程在等待執行.且還有阻塞線程

4.4 mpstat 工具的使用

若是你的系統運行在多處理器芯片上,你可使用 mpstat 命令來監控每一個獨立的芯片.Linux 內核視雙核處理器爲2 CPU’s,所以一個雙核處理器的雙內核就報告有4 CPU’s 可用.

mpstat 命令給出的CPU 利用率統計值大體和 vmstat 一致,可是 mpstat 能夠給出基於單個處理器的統計值.

[root @opt-001 ~ ] # mpstat -P ALL 1
Linux 2.6.18- 164.el5 (opt-001.jobkoo.com ) 09 / 25 / 2009

03: 12: 25 PM CPU %user % nice %sys %iowait %irq %soft %steal %idle intr /s
03: 12: 26 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1010.00
03: 12: 26 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1001.00
03: 12: 26 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
03: 12: 26 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1.00
03: 12: 26 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 7.00

4.5 案例學習: 未充分使用的處理量

在這個例子中,爲4 CPU核心可用.其中2個CPU 主要處理進程運行(CPU 0 和1).第3個核心處理全部內核和其餘系統功能(CPU 3).第4個核心處於idle(CPU 2).

使用 top 命令能夠看到有3個進程差很少徹底佔用了整個CPU 核心.

# top -d 1
top - 23:08: 53 up 8: 34, 3 users, load average: 0.91, 0.37, 0.13
Tasks: 190 total,   4 running, 186 sleeping,   0 stopped,   0 zombie
Cpu (s ): 75.2 % us, 0.2 % sy, 0.0 % ni, 24.5 % id, 0.0 % wa, 0.0 % hi, 0.0 %
si
Mem:   2074736k total,   448684k used, 1626052k free,    73756k buffers
Swap: 4192956k total,        0k used, 4192956k free,   259044k cached

PID USER      PR NI VIRT RES SHR S %CPU %MEM    TIME+ COMMAND
15957 nobody    25   0 2776 280 224 R 100 20.5 0: 25.48 php
15959 mysql     25   0 2256 280 224 R 100 38.2 0: 17.78 mysqld
15960 apache    25   0 2416 280 224 R 100 15.7 0: 11.20 httpd
15901 root      16   0 2780 1092 800 R    1 0.1   0: 01.59 top
1 root      16   0 1780 660 572 S    0 0.0   0: 00.64 init

# mpstat –P ALL 1
Linux 2.4.21- 20.ELsmp (localhost.localdomain )   05 / 23 / 2006

05: 17: 31 PM CPU   %user   % nice %system   %idle    intr /s
05: 17: 32 PM all   81.52    0.00   18.48   21.17    130.58
05: 17: 32 PM    0   83.67    0.00   17.35    0.00    115.31
05: 17: 32 PM    1   80.61    0.00   19.39    0.00     13.27
05: 17: 32 PM    2    0.00    0.00   16.33   84.66      2.01
05: 17: 32 PM    3   79.59    0.00   21.43    0.00      0.00

05: 17: 32 PM CPU   %user   % nice %system   %idle    intr /s
05: 17: 33 PM all   85.86    0.00   14.14   25.00    116.49
05: 17: 33 PM    0   88.66    0.00   12.37    0.00    116.49
05: 17: 33 PM    1   80.41    0.00   19.59    0.00      0.00
05: 17: 33 PM    2    0.00    0.00    0.00 100.00      0.00
05: 17: 33 PM    3   83.51    0.00   16.49    0.00      0.00

05: 17: 33 PM CPU   %user   % nice %system   %idle    intr /s
05: 17: 34 PM all   82.74    0.00   17.26   25.00    115.31
05: 17: 34 PM    0   85.71    0.00   13.27    0.00    115.31
05: 17: 34 PM    1   78.57    0.00   21.43    0.00      0.00
05: 17: 34 PM    2    0.00    0.00    0.00 100.00      0.00
05: 17: 34 PM    3   92.86    0.00    9.18    0.00      0.00

05: 17: 34 PM CPU   %user   % nice %system   %idle    intr /s
05: 17: 35 PM all   87.50    0.00   12.50   25.00    115.31
05: 17: 35 PM    0   91.84    0.00    8.16    0.00    114.29
05: 17: 35 PM    1   90.82    0.00   10.20    0.00      1.02
05: 17: 35 PM    2    0.00    0.00    0.00 100.00      0.00
05: 17: 35 PM    3   81.63    0.00   15.31    0.00      0.00

你也可使用 ps 命令經過查看 PSR 這列,檢查哪一個進程在佔用了哪一個CPU.

while :; do ps -eo pid,ni,pri,pcpu,psr, comm | grep ‘mysqld’; sleep 1; done
PID NI PRI %CPU PSR COMMAND
15775   0 15 86.0   3 mysqld
PID NI PRI %CPU PSR COMMAND
15775   0 14 94.0   3 mysqld
PID NI PRI %CPU PSR COMMAND
15775   0 14 96.6   3 mysqld
PID NI PRI %CPU PSR COMMAND
15775   0 14 98.0   3 mysqld
PID NI PRI %CPU PSR COMMAND
15775   0 14 98.8   3 mysqld
PID NI PRI %CPU PSR COMMAND
15775   0 14 99.3   3 mysqld

4.6 結論

監控 CPU 性能由如下幾個部分組成:

1,檢查system的運行隊列,以及肯定不要超出每一個處理器3個可運行狀態線程的限制.

2,肯定CPU 利用率中user/system比例維持在70/30

3,當CPU 開銷更多的時間在system mode,那就說明已經超負荷而且應該嘗試從新調度優先級

4,當I/O 處理獲得增加,CPU 範疇的應用處理將受到影響