Linux 性能監測：介紹

看了某某教程、讀了某某手冊，按照要求改改某某設置、系統設定、內核參數就認爲作到系統優化的想法很傻很天真：）系統優化是一項複雜、繁瑣、長期的工做，優化前須要監測、採集、測試、評估，優化後也須要測試、採集、評估、監測，並且是一個長期和持續的過程，不是說如今優化了，測試了，之後就能夠一勞永逸了，也不是說書本上的優化就適合眼下正在運行的系統，不一樣的系統、不一樣的硬件、不一樣的應用優化的重點也不一樣、優化的方法也不一樣、優化的參數也不一樣。性能監測是系統優化過程當中重要的一環，若是沒有監測、不清楚性能瓶頸在哪裏，優化什麼呢、怎麼優化呢？因此找到性能瓶頸是性能監測的目的，也是系統優化的關鍵。系統由若干子系統構成，一般修改一個子系統有可能影響到另一個子系統，甚至會致使整個系統不穩定、崩潰。因此說優化、監測、測試一般是連在一塊兒的，並且是一個循環並且長期的過程，一般監測的子系統有如下這些：

• CPU

• Memory

• IO

• Network

這些子系統互相依賴，瞭解這些子系統的特性，監測這些子系統的性能參數以及及時發現可能會出現的瓶頸對系統優化頗有幫助。

應用類型

不一樣的系統用途也不一樣，要找到性能瓶頸須要知道系統跑的是什麼應用、有些什麼特色，好比 web server 對系統的要求確定和 file server 不同，因此分清不一樣系統的應用類型很重要，一般應用能夠分爲兩種類型：

• IO 相關，IO 相關的應用一般用來處理大量數據，須要大量內存和存儲，頻繁 IO 操做讀寫數據，而對 CPU 的要求則較少，大部分時候 CPU 都在等待硬盤，好比，數據庫服務器、文件服務器等。

• CPU 相關，CPU 相關的應用須要使用大量 CPU，好比高併發的 web/mail 服務器、圖像/視頻處理、科學計算等均可被視做 CPU 相關的應用。

看看實際中的例子，第1個是文件服務器拷貝一個大文件時表現出來的特徵：

$ 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  4    140 1962724 335516 4852308  0    0   388 65024 1442  563  0  2 47 52  0
 0  4    140 1961816 335516 4853868  0    0   768 65536 1434  522  0  1 50 48  0
 0  4    140 1960788 335516 4855300  0    0   768 48640 1412  573  0  1 50 49  0
 0  4    140 1958528 335516 4857280  0    0  1024 65536 1415  521  0  1 41 57  0
 0  5    140 1957488 335516 4858884  0    0   768 81412 1504  609  0  2 50 49  0

第2個是 CPU 作大量計算時表現出來的特徵：

$ 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
 4  0    140 3625096 334256 3266584  0    0     0    16 1054  470 100 0  0  0  0
 4  0    140 3625220 334264 3266576  0    0     0    12 1037  448 100 0  0  0  0
 4  0    140 3624468 334264 3266580  0    0     0   148 1160  632 100 0  0  0  0
 4  0    140 3624468 334264 3266580  0    0     0     0 1078  527 100 0  0  0  0
 4  0    140 3624712 334264 3266580  0    0     0    80 1053  501 100 0  0  0  0

上面兩個例子最明顯的差異就是 id 一欄，表明 CPU 的空閒率，拷貝文件時候 id 維持在 50％ 左右，CPU 大量計算的時候 id 基本爲 0。

上面兩個例子最明顯的差異就是 id 一欄，表明 CPU 的空閒率，拷貝文件時候 id 維持在 50％ 左右，CPU 大量計算的時候 id 基本爲 0。

底線

咱們如何知道系統性能是好仍是差呢？這須要事先創建一個底線，若是性能監測獲得的統計數據跨過這條線，咱們就能夠說這個系統性能差，若是數據能保持在線內咱們就說性能好。創建這樣底線須要知道一些理論、額外的負載測試和系統管理員多年的經驗。若是本身沒有多年的經驗，有一個簡單劃底線的辦法就是：把這個底線創建在本身對系統的指望上。本身指望這個系統有個什麼樣的性能，這是一個底線，若是沒有達到這個要求就是性能差。好比，VPSee 上個月有個 RAID0 的測試，指望的測試結果應該是 RAID0 的 IO 性能比單硬盤有顯著提升，底線是 RAID0 的 IO 至少要比單硬盤要好（好多少不重要，底線是至少要好），測試結果卻發現 RAID0 性能還不如單硬盤，說明性能差，這個時候須要問個爲何，這每每是性能瓶頸所在，通過排查發現是原硬盤有硬件瑕疵形成性能測試結果錯誤。

監測工具

咱們只須要簡單的工具就能夠對 Linux 的性能進行監測，如下是 VPSee 經常使用的工具：