Linux 效能監測：介紹

標籤：

看了某某教程、讀了某某手冊，按照要求改改某某設定、系統設定、核心參數就認為做到系統最佳化的想法很傻很天真：）系統最佳化是一項複雜、繁瑣、長期的 工作，最佳化前需要監測、採集、測試、評估，最佳化後也需要測試、採集、評估、監測，而且是一個長期和持續的過程，不是說現在最佳化了，測試了，以後就可以一勞 永逸了，也不是說書本上的最佳化就適合眼下正在啟動並執行系統，不同的系統、不同的硬體、不同的應用最佳化的重點也不同、最佳化的方法也不同、最佳化的參數也不同。性 能監測是系統最佳化過程中重要的一環，如果沒有監測、不清楚效能瓶頸在哪裡，最佳化什麼呢、怎麼最佳化呢？所以找到效能瓶頸是效能監測的目的，也是系統最佳化的關 鍵。系統由若干子系統構成，通常修改一個子系統有可能影響到另外一個子系統，甚至會導致整個系統不穩定、崩潰。所以說最佳化、監測、測試通常是連在一起的， 而且是一個迴圈而且長期的過程，通常監測的子系統有以下這些：

• CPU
• Memory
• IO
• Network

這些子系統互相依賴，瞭解這些子系統的特性，監測這些子系統的績效參數以及及時發現可能會出現的瓶頸對系統最佳化很有協助。

應用類型

不同的系統用途也不同，要找到效能瓶頸需要知道系統跑的是什麼應用、有些什麼特點，比如 web server 對系統的要求肯定和 file server 不一樣，所以分清不同系統的應用類型很重要，通常應用可以分為兩種類型：

• IO 相關，IO 相關的應用通常用來處理大量資料，需要大量記憶體和儲存，頻繁 IO 操作讀寫資料，而對 CPU 的要求則較少，大部分時候 CPU 都在等待硬碟，比如，資料庫伺服器、檔案伺服器等。
• CPU 相關，CPU 相關的應用需要使用大量 CPU，比如高並發的 web/mail 伺服器、映像/視頻處理、科學計算等都可被視作 CPU 相關的應用。

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

$ vmstat 1procs -----------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 1procs -----------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。

底線

我們如何知道系統效能是好還是差呢？這需要事先建立一個底線，如果效能監測得到的統計資料跨過這條線，我們就可以說這個系統效能差，如果資料能保持 線上內我們就說效能好。建立這樣底線需要知道一些理論、額外的負載測試和系統管理員多年的經驗。如果自己沒有多年的經驗，有一個簡單劃底線的辦法就是：把 這個底線建立在自己對系統的期望上。自己期望這個系統有個什麼樣的效能，這是一個底線，如果沒有達到這個要求就是效能差。比如，VPSee 上個月有個 RAID0 的測試， 期望的測試結果應該是 RAID0 的 IO 效能比單硬碟有顯著提高，底線是 RAID0 的 IO 至少要比單硬碟要好（好多少不重要，底線是至少要好），測試結果卻發現 RAID0 效能還不如單硬碟，說明效能差，這個時候需要問個為什麼，這往往是效能瓶頸所在，經過排查發現是原硬碟有硬體瑕疵造成效能測試結果錯誤。

監測工具

我們只需要簡單的工具就可以對 Linux 的效能進行監測，以下是 VPSee 常用的工具：

工具	簡單介紹
top	查看進程活動狀態以及一些系統狀況
vmstat	查看系統狀態、硬體和系統資訊等
iostat	查看CPU 負載，硬碟狀況
sar	綜合工具，查看系統狀況
mpstat	查看多處理器狀況
netstat	查看網路狀況
iptraf	即時網路狀況監測
tcpdump	抓取網路資料包，詳細分析
tcptrace	資料包分析工具
netperf	網路頻寬工具
dstat	綜合工具，綜合了 vmstat, iostat, ifstat, netstat 等多個資訊

一個完整啟動並執行 Linux 系統包括很多子系統（介紹，CPU，Memory，IO，Network，…），監測和評估這些子系統是效能監測的一部分。我們往往需要宏觀的看整個系統狀態，也需要微觀的看每個子系統的運行情況。

幸運的是，我們不必重複造輪子，監控這些子系統都有相應的工具可用，這些經過時間考驗、隨 Unix 成長起來、簡單而優雅的小工具是我們日常 Unix/Linux 工作不可缺少的部分。

下面這張圖片很好的總結了 Linux 各個子系統以及監控這些子系統所需要的工具，如果你對 Linux 系統管理（sysadmin & devops）感興趣、想入門的話，可以從這張圖開始慢慢瞭解和熟悉各個工具。對於熟練的 Linux 屌絲，這張圖你應該能問答自如。（圖片來自：Linux Performance Analysis and Tools，投影片也很精彩，建議對照閱讀。）

Linux 效能監測：介紹