網站運維技術與實踐之伺服器監測常用命令

一、監測的意義

不論是網站運維還是系統管理，伺服器本身的執行狀況都是我們需要掌控的基礎資料。在《打造FaceBook》一書中，王淮介紹FaceBook的工程師文化中有一句“Move Fast and Monitor Closely”。這個"Closely"有兩層意義，其一是“即時”的，要從系統開發初期，就有意識地設計好配套的監測，並逐步改善；其二是“深入”，監控不能僅僅停留在監測主機負載、網路卡流量的表面層次，而要儘可能地細化，以貼近系統的業務特性。

在系統執行和發展的過程中，監測的重要性得到更進一步的提高。運維人員總是傾向於為了保證穩定性而不輕易對系統做任何改動，所以，運維人員對穩定執行中的系統一舉一動都必須要有監測資料的支援。所有的大規模叢集運作，包括近年來流行的自動化管理、彈性控制等理念，都要求我們首先對自己的系統的細節有足夠的瞭解。

1.透過命令瞭解系統的效能概況

1.1 ifconfig命令

 結果包含伺服器的網路卡數目、IP地址、MAC地址、MTU的大小、網路卡收發包的情況(丟包和錯誤包),這些一般是伺服器排除故障時需要檢查的資料。

1.2 w命令

結果中包含伺服器的執行時間、當前使用者及其執行程式，以及1分鐘、5分鐘、10分鐘的平均負載。

或許有人會很疑惑，什麼是平均負載？

平均負載是反映伺服器當前執行狀態最直觀和簡潔的資料。

單核時代，平均負載有如下的經驗準則:

(1)如果平均負載大於0.70，趁著事情沒有向糟糕的方向發展，趕緊開始找原因（關注原則）;

(2)如果負載高於1.00，立刻扔掉其他非重要緊急的事項，先把這個問題修復(針對運維人員,畢竟維護伺服器24x7x365穩定執行是運維人員的職責，沒有什麼是比這個更重要的，因為一旦伺服器出問題，公司的業務也會受到很大的影響)（立刻修復原則）;

(3)如果負載超過5.00，機器隨時可能掛掉，儘可能別出現這種情況，如果出現了，要想盡一切辦法解決，不過更好的解決方案是，前期做了充足的監控準備，防止此類事件出現,用一句成語來形容，防微杜漸。

多核時代，新增兩條準則:

(1)多核系統上，負載不要高過裝置的核心數;

(2)核心如何在CPU分佈，這並不重要。兩個四核心，四個雙核心，八個單核心，效果是一樣的。對於計算平均負載來說，它們都是八核心。

當然了，以上的準則，只是在一定條件的情況下總結出的，每個運維人員所面對的伺服器情況不一樣，需要從實際出發。

比如當核心數多到好幾十時，Linux輪詢各核心來統計單核負載的耗時長到足以讓某些任務狀態變化，這時候平均負載會普遍比實際情況低。針對這種情況，Linux核心社群以及有些補丁儘量調整演算法。

1.3 df

df -h

df -Ti

 分別查詢掛載盤的目錄、總容量和使用量、Inode的總量和使用量，以及磁碟檔案系統的型別。

1.4 ps

ps的用法太多了

比如我經常用的 ps -ef|grep tomcat 檢視tomcat的程式

或者是ps -A檢視所有程式等等

1.5 vmstat

通常會使用free命令檢視機器的記憶體使用情況，如

 或者free -m(以"兆"的形式顯示記憶體的容量)

vmstat 1 可以用來觀察swap的I/O情況，如圖:

1.6 netstat

netstat 是檢視網路相關資料的常用命令，可以用來檢視伺服器所有的網路層連線狀況。

netstat -plnt 命令

1.7 iostat

iostat -x 命令

其中磁碟裝置的資料含義如下:

rrqm/s:合併後每秒傳送到裝置的讀入請求數。

wrqm/s:合併後每秒傳送到裝置的寫入請求數。

r/s:每秒傳送到裝置的讀入請求數。

w/s:每秒傳送到裝置的寫入請求數。

rsec/s:每秒從裝置讀入的扇區數。

wsec/s:每秒從裝置寫入的扇區數。

rkB/s:每秒從裝置讀入的資料量，單位為KB。

wkB/s:每秒向裝置寫入的資料量，單位為KB。

avgrq-sz:傳送到裝置的請求的平均大小，單位是扇區。

avgqu-sz：傳送到裝置的請求的平均佇列長度。

await:I/O請求平均執行時間，包括髮送請求和執行時間，單位是毫秒。

svctm:傳送到裝置的I/O請求的平均執行時間。單位是毫秒。

$util:在I/O請求傳送到裝置期間，佔用CPU時間的百分比。

一般來說，我們關心每秒的讀入請求數、佇列長度、請求執行時間和I/O時間佔CPU的百分比。

對於磁碟I/O，我們必須要明確一件事情，那就是:

I/O效能的最佳化是不可能無限提高的。所有機械磁碟的IOPS都在最根本上受限於其機械轉動的原理。

原文出處： https://www.cnblogs.com/youcong/p/9932256.html