概述

　　機器負載是否正常，經常需要監控的指標有如下4個：

　　　　<1> cpu

　　　　<2> memory

　　　　<3> IO

　　　　<4> network

關於cpu的監控

　　a. load average，cpu的負載

　　　linux進程的狀態分類可以粗略地分為 blocking process， runnable process，running process。分別為等待IO資源，或者自己調用了wait和sleep系列的函數被掛起的進程；所有資源都就位了，就等cpu的進程；正在cpu上跑的進程。cpu的 load average 是根據特定時間段內，runnable process 和 running process 綜合統計情況。在單核cpu上，如果 load average 在 0 到 1 之間表示 cpu 還有剩余資源，進程運行通暢。等於1表示系統已經沒有剩余的cpu資源了，對於多個進程滿打滿算剛夠用。如果超過1，則說明系統此時正在超負荷運行。load average 一般維持在0.7左右比較好。對於2個cpu核心的機器，那麽load average超過2才說明系統正在超負荷運行。其他的以此類推。可以獲得 load average 的方法很多，比如

　　　 top命令

　　　uptime命令

　　　查看cpu核數

　　　load average 的3個數字展示的分別是1分鐘，5分鐘，15分鐘的統計數據。可以看到我的cpu是24核的，但是 load average 沒有達到1，說明cpu資源很富裕，基本沒有等待cpu資源的進程，cpu資源永遠是等待被使用的。

　　b. cpu utilization， cpu的利用率

　　　　在linux下，cpu的狀態可以分為用戶態，內核態和空閑態。當cpu運行的是用戶的代碼時，cpu處於用戶態。當代碼發生系統調用或者發生其他一些中斷時，cpu就會運行內核的代碼，此時cpu處於內核態。現在cpu的執行速度是很快的，所以正常情況下，有很大一部分時間內linux系統中所有進程都是被掛起的，這時候cpu會運行系統內的零號進程。這個零號進程在早期是空循環，後來為了節約資源，有了高級電源管理，這個零號進程的主要幹的事就是調用高級電源管理相關功能，把cpu主頻降下來，降低發熱和損耗。cpu運行零號進程時，就處於空閑態。在linux系統中同樣存在很多命令去查看特定時間段內，cpu這幾種狀態所占的比例，

　　　 top命令　

　　　vmstat命令

　　 cpu utilization 的計算方式是： cpu% = cpu非零號進程的時間 / cpu執行時間的總和。

　　 所以 cpu utilization 展示的是cpu的運行狀態。如果 cpu utilization 一直處於100%，說明cpu一直處於用戶態或者內核態，沒有時間去執行零號進程去降低主頻去休息。

　　 cpu utilization 的概念和 cpu load average 很容易混淆。cpu load average 側重的是cpu資源的爭奪情況，比如進程/線程多，但是cpu核數不夠使，load average 就會高。cpu utilzation 側重的是cpu真實地執行邏輯運算的情況。比如現在有100個進程，但是只有1個cpu，但是這100個進程裏面有大量的網絡IO或者磁盤IO, 在這時 cpu average 會很高，但是 cpu utilzation 不一定高，因為IO只需要cpu執行很少的邏輯運算，大部分時間在等待。舉個例子就明白了，比如寫了這樣一個代碼：while(1) { i = i + 1; }， 假設這臺機器上只有這樣的一個進程，那麽只要這個進程起來， cpu utilization 就會飆到很高，因為執行了大量的邏輯運算。但是 cpu load average 反而會很低，因為沒有進程等待使用CPU。

　　c. cpu csr， csr 即 context switch rate, cpu上下文切換率。

　　　　上下文切換很好理解。上下文切換本質上就是進程或者線程的切換。發生進程/線程的切換籠統地來說，一般有兩種情況，進程的cpu時間片用完了，進程阻塞了或者中斷到來了，這時候會發生進程/線程的切換，也就是上下文切換。得到系統每秒上下文切換次數的信息一般用以下放法：

　　　　vmstat 1， 表示每1秒采集一次信息，直到手動ctrl-c

　　　　這個值一般情況下越小越好。因為如果這個值很大，cpu cs 很大，說明cpu很多時間都浪費在進程/線程的切換上，而不是執行進程/線程本身的邏輯。　　

　　看cpu的資源是否夠用一般需要靈活使用這3個參數。

　　如果sy很高，但是us很低，同時cs較高，則代碼此時正在進行大量的系統調用，這個時候要好好考察一下代碼邏輯了，是否真的需要那麽多次的系統調用，因為很多cpu時間都會浪費到上下文切換中。

　　再比如，如果只是 cpu cs 很高，但是 cpu utilization 不高，這種情況也是可以接受的。說明有很多進程/線程同時在運行，但是計算密集度並不高，cpu也並沒有壓力山大。

　　再比如我們線上最近出的一次事故，mysql突然很慢，但是運行的代碼邏輯並沒有改變。後來查到原因是，增加了這套代碼運行的進程個數，導致mysql那臺機器上線程數過多，cpu在做瘋狂地上下文切換，導致mysql性能降低。從下面的zabbix監控圖中也可以看出，平時cs很低，但是增加了進程個數之後，cs突然變得很高，同時 cpu utilization 也變得很高

關於memory的監控

　　memory主要監控的指標就是剩余內存的量。因為很多代碼會發生內存泄漏的問題，這樣就會導致代碼跑的時間越長，機器內存越少，最後代碼因為申請不到內存而停止工作或者直接死掉。

　　主要使用到的命令是free。

　　　　調用free命令會輸出如下信息

　　　　Mem這一行很容易理解。total就是所有內存，used是已經使用的內存，free是剩余的內存。shared是進程間的共享內存，一般用不到。buffer是已經分配但是未使用的buffer大小。cached也一樣，已經分配但是未使用的cache大小。free命令輸出的buffer和cache可以這樣理解，buffer是內存和塊設備之間的速度均衡器，cache是cpu和內存之間的速度均衡器。linux從磁盤讀取出來的內容會緩存在內存cache中，如果再用到就不用再從磁盤中讀取。buffer會把一些隨機的小的IO緩存起來，通過計算形成盡量連續的IO，減少磁盤頻繁尋道，提高IO效率。 -/+ buffer/cache這一行就令人費解了。註意，Mem這一行中和-/+buffers/cache這一行中，都是used+free=total。那麽-/+ buffer/cache這一行到底怎麽理解。如果不深究，有一種比較簡單的理解方法：Mem是從系統的角度來看待內存的使用的，used包括分配給應用程序和buffer/cache的物理內存，free就是真真實實沒有使用的物理內存。而-/+buffers/cache是從應用程序的角度看的，因為應用程序認為分配給buffer/cache的物理內存如果需要用的話，可以直接回收，所以-/+buffers/cache中的free要比Mem中的free小得多。一般監控-/+buffers/cache這一行，看系統中的內存是否夠用。

　　　　swap也是一個監控指標，如果swap這一行額used不為0，就說明機器上內存不夠用了。這時候就要考慮改進應用程序或者遷移應用程序到內存更大的機器上。

關於IO的監控

　　一般使用sar命令來查看磁盤的IO性能。

　　await是一次IO等待的時間，可以近似認為是一次IO的時間，毫秒

　　svctm是每次IO的操作中，IO操作的服務時間，主要是磁盤性能，並且CPU，內存負載也可能在一定程度上增加svctm的值

　　util，一秒鐘之內有百分之幾用於IO操作。

　　await值的大小一般取決與svctm的值和I/O隊列長度以及I/O請求模式，如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，如果await的值遠高於svctm的值，則表示I/O隊列等待太長，系統上運行的應用程序將變慢，此時可以通過更換更快的硬盤來解決問題。
%util項的值也是衡量磁盤I/O的一個重要指標，如果%util接近100%，表示磁盤產生的I/O請求太多，I/O系統已經滿負荷的在工作，該磁盤可能存在瓶頸。長期下去，勢必影響系統的性能，可以通過優化程序或者通過更換更高、更快的磁盤來解決此問題。參考自：http://88fly.blog.163.com/blog/static/1226803902012514710581/

關於network的監控

　　關於網絡的監控我認為需要註意2點：

　　　　1. 寫代碼的時候需要註意的問題，之前寫過這樣的一個代碼：

　　　　　　可以註意到，如果$url那邊的服務出錯，我這邊會while死循環 curl_init + curl_close。 但是主動關閉TCP連接會進入TIME_WAIT狀態，所以我的機器上就出現了大量TIME_WAIT的socket，直接把機器的文件描述符資源耗盡了。

　　　　2. 正兒八經的監控

　　　　　　netstat -lnu

　　　　　　主要看Recv-Q和Send-Q中有沒有積壓的數據。如果網絡狀態良好，這兩個值一般為0。如果長時間不為0，則可能有問題。如果Recv-Q滿了，但是還有人往這個UDP端口發送數據，那麽內核就會把接收到的數據丟棄了。UDP也沒有重傳機制，這樣數據就算是丟了，而且對端在UDP這一層毫無感知。或者通過netstat -su, 會輸出一個“packet receive errors”的信息，這個信息一般情況下表示的是，網卡收到了，但是應用層沒有來得及處理而造成丟的包的個數。

常見的機器負載監控指標