Linux 性能監控： CPU 、Memory 、 IO 、Network

時間 2019-12-13

標籤 linux 性能監控 cpu memory network 欄目 Linux 简体版

原文原文鏈接

Linux 性能監控： CPU 、Memory 、 IO 、Network

	指標linux	工具ios
cpu緩存	usr<=70%, sys<=35%, usr+sys<=70%服務器	top網絡
memorytcp	si == so == 0 可用空間>=30%工具	vmstat 1;free; /proc/meminfo性能
iospa	iowait% < 20%線程	iostat -x;
network	udp：緩衝區不擠壓, 無丟包 tcp：重傳率	netstat -lunp; netstat -su; /proc/net/snmp

1、CPU

1.良好狀態指標

CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%
上下文切換：與CPU利用率相關聯，若是CPU利用率狀態良好，大量的上下文切換也是能夠接受的
可運行隊列：每一個處理器的可運行隊列<=3個線程

2.監控工具

top 最經常使用略
vmstat

$ vmstat 1 （1 表示 1s 輸出一次）
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0
17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0
20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0
17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0
16  0    140 2904580 341912 3952108  0    0     0     0 1055 9808 34 65  1  0  0

重要參數：

r，run queue，可運行隊列的線程數，這些線程都是可運行狀態，只不過CPU暫時不可用； b，被blocked的進程數，正在等待IO請求； in，interrupts，被處理過的中斷數 cs，context switch，系統上正在作上下文切換的數目 us，用戶佔用CPU的百分比 sys，內核和中斷佔用CPU的百分比 id，CPU徹底空閒的百分比

上例可得：

sy高us低，以及高頻度的上下文切換（cs），說明應用程序進行了大量的系統調用；

這臺4核機器的r應該在12個之內，如今r在14個線程以上，此時CPU負荷很重。

查看某個進程佔用的CPU資源$ while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'db_server_login'; sleep 1; done PID NI PRI %CPU PSR COMMAND 28577 0 23 0.0 0 db_server_login 28578 0 23 0.0 3 db_server_login 28579 0 23 0.0 2 db_server_login 28581 0 23 0.0 2 db_server_login 28582 0 23 0.0 3 db_server_login 28659 0 23 0.0 0 db_server_login ……

2、Memory

1.良好狀態指標

swap in （si） == 0，swap out （so） == 0
應用程序可用內存/系統物理內存 <= 70%

2.監控工具

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 st
 1  0 2085940 402932 245856 8312440    1    1    15   172    0    0  7  5 88  0  0
 1  0 2085940 400196 245856 8315148    0    0   532     0 4828 9087 30  6 63  1  0
 2  0 2085940 397716 245868 8317908    0    0   464   552 4311 8427 29  6 65  0  0
 2  0 2085940 393144 245876 8322484    0    0   584  2556 4620 9054 30  5 65  0  0
 2  0 2085940 389368 245876 8325408    0    0   592     0 4460 8779 30  5 65  0  0

重要參數：

swpd，已使用的 SWAP 空間大小，KB 爲單位 free，可用的物理內存大小，KB 爲單位 buff，物理內存用來緩存讀寫操做的buffer大小，KB 爲單位 cache，物理內存用來緩存進程地址空間的 cache 大小，KB 爲單位 si，數據從 SWAP 讀取到 RAM（swap in）的大小，KB 爲單位 so，數據從 RAM 寫到 SWAP（swap out）的大小，KB 爲單位

上例可得：

物理可用內存 free 基本沒什麼顯著變化，swapd逐步增長，說明最小可用的內存始終保持在 256MB(物理內存大小) * 10％ = 2.56MB 左右，當髒頁達到10％的時候就開始大量使用swap。

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  3 252696   2432    268   7148 3604 2368  3608  2372  288  288  0  0 21 78  1
0  2 253484   2216    228   7104 5368 2976  5372  3036  930  519  0  0  0 100  0
0  1 259252   2616    128   6148 19784 18712 19784 18712 3821 1853  0  1  3 95  1
1  2 260008   2188    144   6824 11824 2584 12664  2584 1347 1174 14  0  0 86  0
2  1 262140   2964    128   5852 24912 17304 24952 17304 4737 2341 86 10  0  0  4
^C

free

$ free
             total       used       free     shared    buffers     cached
Mem:      15728640   15600636     128004          0          0   13439080
-/+ buffers/cache:    2161556   13567084
Swap:      2104508     276276    1828232

單位KB。能夠用 -m 選項要求輸出單位爲MB。

咱們使用total一、used一、free一、used二、free2 等名稱來表明上面統計數據的各值，一、2 分別表明第一行和第二行的數據。

total1：表示物理內存總量。 used1：表示總計分配給緩存（包含buffers 與cache ）使用的數量，但其中可能部分緩存並未實際使用。 free1：未被分配的內存。 shared1：共享內存，通常系統不會用到，這裏也不討論。 buffers1：系統分配但未被使用的buffers 數量。 cached1：系統分配但未被使用的cache 數量。buffer 與cache 的區別見後面。 used2：實際使用的buffers 與cache 總量，也是實際使用的內存總量。 free2：未被使用的buffers 與cache 和未被分配的內存之和，這就是系統當前實際可用內存。

cache 和 buffer的區別：

Cache：高速緩存，是位於CPU與主內存間的一種容量較小但速度很高的存儲器。

因爲CPU的速度遠高於主內存，CPU直接從內存中存取數據要等待必定時間週期，Cache中保存着CPU剛用過或循環使用的一部分數據，當CPU再次使用該部分數據時可從Cache中直接調用,這樣就減小了CPU的等待時間,提升了系統的效率。

Cache又分爲一級Cache(L1 Cache)和二級Cache(L2 Cache)，L1 Cache集成在CPU內部，L2 Cache早期通常是焊在主板上,如今也都集成在CPU內部，常見的容量有256KB或512KB L2 Cache。

Buffer：緩衝區，一個用於存儲速度不一樣步的設備或優先級不一樣的設備之間傳輸數據的區域。經過緩衝區，可使進程之間的相互等待變少，從而使從速度慢的設備讀入數據時，速度快的設備的操做進程不發生間斷。

Free中的buffer和cache：（它們都是佔用內存）

buffer : 做爲buffer cache的內存，是塊設備的讀寫緩衝區

cache: 做爲page cache的內存，文件系統的cache

若是 cache 的值很大，說明cache住的文件數不少。若是頻繁訪問到的文件都能被cache住，那麼磁盤的讀IO 必會很是小。

$ cat /proc/meminfoMemTotal: 15728640 kB MemFree: 116196 kB Buffers: 0 kB Cached: 13448268 kB ……

這臺服務器總共有 8GB 物理內存（MemTotal），3GB 左右可用內存（MemFree），343MB左右用來作磁盤緩存（Buffers），4GB左右用來作文件緩存區（Cached）。用free命令也能夠查到這幾個值，注意單位是kB。

3、磁盤IO

1.良好狀態指標

iowait % < 20% 提升命中率的一個簡單方式就是增大文件緩存區面積，緩存區越大預存的頁面就越多，命中率也越高。 Linux 內核但願能儘量產生次缺頁中斷（從文件緩存區讀），而且能儘量避免主缺頁中斷（從硬盤讀），這樣隨着次缺頁中斷的增多，文件緩存區也逐步增大，直到系統只有少許可用物理內存的時候 Linux 纔開始釋放一些不用的頁。

2.監控工具

$ sar -d 2 3 （2秒一次 共3次）
Linux 3.10.83-1-tlinux2-0021.tl1 (xgame_9_zone1)        06/22/17        _x86_64_        (48 CPU)

16:50:05          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:07       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

16:50:07          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:09       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

16:50:09          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
16:50:11       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

Average:          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
Average:       dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

重要參數：

await表示平均每次設備I/O操做的等待時間（以毫秒爲單位）。 svctm表示平均每次設備I/O操做的服務時間（以毫秒爲單位）。 %util表示一秒中有百分之幾的時間用於I/O操做。

若是svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，若是await的值遠高於svctm的值，則表示I/O隊列等待太長，系統上運行的應用程序將變慢。

若是%util接近100%，表示磁盤產生的I/O請求太多，I/O系統已經滿負荷的在工做，該磁盤可能存在瓶頸。

$ iostat -x（選項 -x 用於顯示和io相關的擴展數據）

Linux 3.10.83-1-tlinux2-0021.tl1 (xgame_9_zone1)        06/22/17        _x86_64_        (48 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.46    0.00    2.75    0.01    0.00   94.78

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00   153.95     0.00    1.02   0.47   0.00

查看哪一個進程佔IO：iotop，效果和top看cpu同樣。查看某個進程打開的文件：/proc/${pid}/fd

4、Network IO

對於UDP

1.良好狀態指標

接收、發送緩衝區不長時間有等待處理的網絡包

2.監控工具

netstat

對於UDP服務，查看全部監聽的UDP端口的網絡狀況

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:64000           0.0.0.0:*                           -
udp        0      0 0.0.0.0:38400           0.0.0.0:*                           -
udp        0      0 0.0.0.0:38272           0.0.0.0:*                           -
udp        0      0 0.0.0.0:36992           0.0.0.0:*                           -
udp        0      0 0.0.0.0:17921           0.0.0.0:*                           -
udp        0      0 0.0.0.0:11777           0.0.0.0:*                           -
udp        0      0 0.0.0.0:14721           0.0.0.0:*                           -
udp        0      0 0.0.0.0:36225           0.0.0.0:*                           -

RecvQ、SendQ爲0，或者不長時間有數值是比較正常的。

對於UDP服務，查看丟包狀況（網卡收到了，可是應用層沒有處理過來形成的丟包）

$ watch netstat -su
Udp:
    278073881 packets received
    4083356897 packets to unknown port received.
    2474435364 packet receive errors
    1079038030 packets sent

packet receive errors 這一項數值增加了，則代表在丟包。

對於TCP（來自davidshan單衛的經驗，thx~）

1.良好狀態指標

對於TCP而言，不會出現由於緩存不足而存在丟包的事，由於網絡等其餘緣由，致使丟了包，協議層也會經過重傳機制來保證丟的包到達對方。

因此，tcp而言更多的專一重傳率。

二、監控工具

經過snmp能夠查看各層網絡協議的收發包的狀況

$ cat /proc/net/snmp | grep Tcp
Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts
Tcp: 1 200 120000 -1 78447 413 50234 221 3 5984652 5653408 156800 0 849

重傳率 = RetransSegs / OutSegs

至於這個值在多少範圍內，算ok的，得看具體的業務了。

業務側更關注的是響應時間。