CPU監控

• 一，關鍵概念
  • 1，Context Switches（上下文切換）
  • 2，The run Queue（運行隊列）
  • 3，CPU的使用率
• 二，CPU監控
  • 2.1，健康狀態下CPU基準線
  • 2.2，vmstat使用
    • 2.2.1 使用辦法
    • 2.2.2 Case分析
      • case1：
      • case 2：
  • 2.3，mpstat使用
    • case 1:

 

服務器內核有個調度器，其負責調度兩種資源（線程，中斷）。調度器針對不一樣的資源有不一樣的優先級，下面三個優先級從高到低依次以下：

1. 中斷：設備完成操做後通知內核，例如硬件設備受到一個IO請求
2. 系統進程：全部內核操做都在這個級別
3. 用戶進程：這些進程通常都運行在用戶空間中，其在調度器中優先級比較低

下面分別詳細介紹一些關鍵概念

一，關鍵概念

1，Context Switches（上下文切換）

如今的CPU大部分在同一顆核上同時只能跑一個線程，就算超線程處理器，微觀上看同一時刻也只是跑一個線程。Linux內核看每顆CPU處理器都是獨立處理器。一個Linux內核同時能夠調度50-50000個線程。在每顆處理器中調度器都須要調度線程合理的使用CPU。每一個線程分配了一個時間片的時間使用CPU，一旦時間片用完了或者高優先級資源（例如中斷）須要佔用CPU，該線程就會放回到調度隊列中讓高優先級資源使用CPU。這樣的線程切換就是所謂的Context Switch（上下文切換）。每發生一次上下文切換資源就會從CPU的使用中挪到調度隊列中。一個系統單位之間內上下文切換的次數越多，代表內核進行的工做越繁忙。

2，The run Queue（運行隊列）

每一個CPU都維護了一個運行隊列，理想來說調度器會一直處於運行和執行線程，這些線程不是處於運行狀態就是休眠狀態（等待IO或者阻塞）。若是CPU子系統的使用率很是高的狀況下，內核調度程序可能跟不上系統的須要。會致使運行隊列愈來愈大，同時一些可運行的線程一直得不到調度。

下面說明下load的概念：

load常常用來描述運行隊列的情況。其含義是正在執行的線程個數與運行隊列中線程個數的和。例如一個雙核系統，如今有兩個線程在執行，有4個線程在運行隊列。

因此此時load爲6。Linux提供了最近1min，5min，15min的統計。

3，CPU的使用率

CPU的使用率是指CPU使用百分比，該指標是系統CPU使用狀況重要指標。大部分監控工具提供了以下四個維度的監控

1. User Time（用戶時間）：用戶空間中的用戶態線程使用CPU耗時佔整個時間段比例
2. System Time（系統時間）：系統線程（or 進程）使用CPU耗時佔整個時間段比例
3. Wait IO：由於等待IO請求空閒時間佔整個時間段比例
4. Idle：徹底空閒時間佔比

二，CPU監控

2.1，健康狀態下CPU基準線

1. 單核CPU，load不超過3個task。通常線上機器單核load超過1.5就該引發注意了。
2. User Time不超過65%-70%
3. System Time不超過30%
4. 通常線上狀況CPU使用率到80%，就應該加機器，或者想辦法優化了。
5. 上線文切換直接相關CPU的使用程度

2.2，vmstat使用

2.2.1 使用辦法

vmstat {採樣時間間隔,單位爲秒}

vmstat  1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----   r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa   2   0  181124  150552    7404  606060     0     0    380    185     0     0  47   1  50   1   1   0  181124  149496    7412  606736     0     0    229     17  1245  1757  25   1  73   0   1   0  181124  148552    7420  607564     0     0    280     39  1331  1858  26   1  72   1   1   0  181124  145484    7428  610820     0     0   1053     23  1161  1728  24   1  73   1

下面只解釋CPU相關的列

各列名稱	含義	備註
r	運行隊列中任務數（線程數）
b	被阻塞或者等待IO請求的線程數
in	interrupte：處理的中斷數
cs	context switches：上下文切換數
us	user time:用戶進程消耗時間比
sy	system time:系統進程消耗時間比
id	idle：空間時間比

2.2.2 Case分析

case1：

# vmstat  1 procs memory swap io system cpu r b swpd   free  buff  cache  si    so bi bo    in cs us sy         wa id 3  0  206564  15092  80336  176080  0      0    0  0      718  26  81  19         0  0 2  0  206564  14772  80336  176120  0      0    0  0      758  23  96  4          0  0 1  0  206564  14208  80336  176136  0      0    0  0      820  20  96  4          0  0 1  0  206956  13884  79180  175964  0      412  0  2680   1008  80  93  7         0  0 2  0  207348  14448  78800  175576  0      412  0  412    763  70  84  16         0  0 2  0  207348  15756  78800  175424  0      0    0  0      874  25  89  11         0  0 1  0  207348  16368  78800  175596  0      0    0  0      940  24  86  14         0  0 1  0  207348  16600  78800  175604  0      0    0  0      929  27  95  3          0  2 3  0  207348  16976  78548  175876  0      0    0  2508   969  35  93  7          0  0 4  0  207348  16216  78548  175704  0      0    0  0      874  36  93  6          0  1 4  0  207348  16424  78548  175776  0      0    0  0      850  26  77  23         0  0 2  0  207348  17496  78556  175840  0      0    0  0      736  23  83  17         0  0 0  0  207348  17680  78556  175868  0      0    0  0      861  21  91  8          0  1

從這個case能夠看出：

1. 當前CPU幾乎都徹底吃滿，同時可運行隊列中任務有堆積
2. 系統有在使用swap，狀況很是糟糕
3. 內存也很是緊張，可用內存不多
4. 線程上下文切換比中斷少不少。猜想是個單線程在工做的樣子（須要業務知識驗證），若是不是從業務知識下判斷
5. 線上服務通常不容許出現這麼糟糕的狀況

case 2：

# vmstat  1 procs memory swap io system cpu r b swpd    free    buff    cache   si so   bi  bo      in  cs      us sy   wa id 2  1  207740   98476    81344  180972     0  0      2496  0       900  2883     4  12     57  27 0  1  207740   96448    83304  180984     0  0      1968  328     810  2559     8  9      83  0 0  1  207740   94404    85348  180984     0  0      2044  0       829  2879     9  6      78  7 0  1  207740   92576    87176  180984     0  0      1828  0       689  2088     3  9      78  10 2  0  207740   91300    88452  180984     0  0      1276  0       565  2182     7  6      83  4 3  1  207740   90124    89628  180984     0  0      1176  0       551  2219     2  7      91  0 4  2  207740   89240    90512  180984     0  0      880  520      443  907      22  10    67  0 5  3  207740   88056    91680  180984     0  0      1168  0       628  1248     12  11    77  0 4  2  207740   86852    92880  180984     0  0      1200  0       654  1505     6  7      87  0 6  1  207740   85736    93996  180984     0  0      1116  0       526  1512     5  10     85  0 0  1  207740   84844    94888  180984     0  0      892  0        438  1556     6  4      90  0

從這個case能夠得出下面結論：

1. 線程上線文切換相比中斷要頻繁，內核消耗大量的時間完成上下文切換。
2. CPU負載嚴重不均衡，用戶進程消耗不多的CPU，可是大量的時間都在等待IO
3. 由於CPU在等待IO，致使有些任務被block住了

2.3，mpstat使用

由於如今大多服務器都是多核，能夠採用mpstat命令查看每一個單核CPU的使用狀況

sankuai @mobile -moviesolr02:~$ mpstat -P ALL  1 Linux  3.2 . 0 - 34 -virtual (mobile-moviesolr02)      10 / 16 / 2015   _x86_64_    ( 4  CPU) 05 : 35 : 41  PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle 05 : 35 : 42  PM  all    25.81     0.00     1.25     0.50     0.00     0.00     0.00     0.00    72.43 05 : 35 : 42  PM     0     1.00     0.00     1.00     0.00     0.00     0.00     0.00     0.00    98.00 05 : 35 : 42  PM     1    35.71     0.00     0.00     0.00     0.00     0.00     0.00     0.00    64.29 05 : 35 : 42  PM     2     6.93     0.00     3.96     0.00     0.00     0.00     0.00     0.00    89.11 05 : 35 : 42  PM     3    59.41     0.00     0.99     0.99     0.00     0.00     0.00     0.00    38.61   05 : 35 : 42  PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle 05 : 35 : 43  PM  all    25.81     0.00     1.25     0.00     0.00     0.00     0.25     0.00    72.68 05 : 35 : 43  PM     0     0.00     0.00     1.01     0.00     0.00     0.00     0.00     0.00    98.99 05 : 35 : 43  PM     1     0.99     0.00     1.98     0.00     0.00     0.00     0.00     0.00    97.03 05 : 35 : 43  PM     2     8.00     0.00     2.00     0.00     0.00     0.00     0.00     0.00    90.00 05 : 35 : 43  PM     3    95.92     0.00     0.00     0.00     0.00     0.00     0.00     0.00     4.08

case 1:

#經過top -d  1  能夠找出消耗CPU的大戶 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   ##而後能夠看該進程在哪顆CPU上面，以及優先級如何 while  :;  do  ps -eo pid,ni,pri,pcpu,psr,comm | grep  'java' ; 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 ##PSR表示運行於第幾顆CPU

 

參考：

1. Linux調度器詳解：https://www.ibm.com/developerworks/cn/linux/l-scheduler/