linux效能監控 -CPU、Memory、IO、Network等指標的講解
[作業系統-linux]linux效能監控 -CPU、Memory、IO、Network等指標的講解(轉)
一、CPU
1、良好狀態指標
- CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。
- 上下文切換：與CPU利用率相關聯，如果CPU利用率狀態良好，大量的上下文切換也是可以接受的。
- 可執行佇列：每個處理器的可執行佇列<=3個執行緒。
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
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 'test_command'; sleep 1; done
PID NI PRI %CPU PSR COMMAND
28577 0 23 0.0 0 test_command
28578 0 23 0.0 3 test_command
28579 0 23 0.0 2 test_command
28581 0 23 0.0 2 test_command
28582 0 23 0.0 3 test_command
28659 0 23 0.0 0 test_command
……
二、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
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
重要引數：
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。
- free
$ free -m
total used free shared buffers cached
Mem: 8111 7185 926 0 243 6299
-/+ buffers/cache: 643 7468
Swap: 8189 0 8189
三、磁碟IO
1、良好狀態指標
- iowait % < 20%
提高命中率的一個簡單方式就是增大檔案快取區面積，快取區越大預存的頁面就越多，命中率也越高。
Linux 核心希望能儘可能產生次缺頁中斷（從檔案快取區讀），並且能儘可能避免主缺頁中斷（從硬碟讀），這樣隨著次缺頁中斷的增多，檔案快取區也逐步增大，直到系統只有少量可用實體記憶體的時候 Linux 才開始釋放一些不用的頁。
2、監控工具
- 檢視實體記憶體和檔案快取情況
$ cat /proc/meminfo
MemTotal: 8182776 kB
MemFree: 3053808 kB
Buffers: 342704 kB
Cached: 3972748 kB
這臺伺服器總共有 8GB 實體記憶體（MemTotal），3GB 左右可用記憶體（MemFree），343MB左右用來做磁碟快取（Buffers），4GB左右用來做檔案快取區（Cached）。
- sar
$ sar -d 2 3
Linux 2.6.9-42.ELsmp (webserver) 11/30/2008 _i686_ (8 CPU)
11:09:33 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:35 PM dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11:09:35 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:37 PM dev8-0 1.00 0.00 12.00 12.00 0.00 0.00 0.00 0.00
11:09:37 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:39 PM dev8-0 1.99 0.00 47.76 24.00 0.00 0.50 0.25 0.05
Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
Average: dev8-0 1.00 0.00 19.97 20.00 0.00 0.33 0.17 0.02
重要引數：
await表示平均每次裝置I/O操作的等待時間（以毫秒為單位）。
svctm表示平均每次裝置I/O操作的服務時間（以毫秒為單位）。
%util表示一秒中有百分之幾的時間用於I/O操作。
如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁碟效能很好，如果await的值遠高於svctm的值，則表示I/O佇列等待太長，系統上執行的應用程式將變慢。
如果%util接近100%，表示磁碟產生的I/O請求太多，I/O系統已經滿負荷的在工作，該磁碟可能存在瓶頸。
四、Network IO
對於UDP
1、良好狀態指標
接收、傳送緩衝區不長時間有等待處理的網路包
2、監控工具
- netstat
對於UDP服務，檢視所有監聽的UDP埠的網路情況
$ watch netstat -lunp
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 這一項數值增長了，則表明在丟包。
這裡有對“packet receive errors”的稍微詳細些的解釋，它包含了7種錯誤，and通常表明是checksum錯誤。不過我們通常通過這個數值的變化來判斷UDP服務是否丟包（第2項錯誤），不知道是否有其他什麼方法來判斷UDP的丟包？：
"packet receive errors" usually means:
1) data is truncated, error in checksum while copying
2) udp queue is full, so it needs to be dropped
3) unable to receive udp package from encapsulated socket
4) sock_queue_rcv_skb() failed with -ENOMEM
5) it is a short packet
6) no space for header in udp packet when validating packet
7) xfrm6_policy_check() fails
many times it means the checksum is not right.
對於TCP（來自david的經驗，thx~~）
1、良好狀態指標
對於TCP而言，不會出現因為快取不足而存在丟包的事，因為網路等其他原因，導致丟了包，協議層也會通過重傳機制來保證丟的包到達對方。
所以，tcp而言更多的專注重傳率。
2、監控工具
# 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的，得看具體的業務了。
業務側更關注的是響應時間。