三種系統監控工具對比：top vs Htop vs Glances

下面是一些挑戰：

A.交互仍是批處理模式？

默認狀況下，Top 被調用時使用交互模式。在此模式下，Top 無限期運行，並能夠經過按鍵從新定義 Top 的運行方式。可是，有時你須要對 Top 的輸出進行後續處理，但這在此模式下難以實現。解決方法？使用批處理模式。

$ top -b

你將得到相似下面的輸出：

top - 15:22:45 up  4:19,  5 users,  load average: 0.00, 0.03, 0.00 Tasks: 60 total, 1 running, 59 sleeping, 0 stopped, 0 zombie Cpu(s): 3.8% us, 2.9% sy, 0.0% ni, 89.6% id, 3.3% wa, 0.4% hi, 0.0% si Mem: 515896k total, 495572k used, 20324k free, 13936k buffers Swap: 909676k total, 4k used, 909672k free, 377608k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 16 0 1544 476 404 S 0.0 0.1 0:01.35 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/0 3 root 10 -5 0 0 0 S 0.0 0.0 0:00.11 events/0

哈，等等，它是不斷重複運行的，同交互模式同樣。不用擔憂，你可使用 -n 限制重複數量。因此，若是你但願得到一次性結果，鍵入：

$ top -b -n 1

這一模式的真正優點在於你能夠很容易的與 at 或 cron 命令結合。它們的結合，使得 Top 能夠在特定時間對資源使用狀態進行快照。例如，使用 at ，咱們能夠設定 top 在一分鐘以後運行。

$ cat ./test.at TERM=linux top -b -n 1 >/tmp/top-report.txt $ at -f ./test.at now+1minutes

細心的讀者可能會問「在建立新任務時，爲何我須要在調用 Top 以前設置環境變量 TERM？」。答案是，Top 運行時須要此變量，但「at」在定時調用時並不會保留它。同上面那樣簡單的設置能夠確保 Top 正常運行。

翻譯於 2013/04/10 14:00

頂

4

B.如何監控制定進程？

有時，咱們只對幾個進程感興趣，可能只是所有進程中的4個或5個。例如，若是你想要監測進程標識（PID）爲4360和4358的進程，你須要鍵入：

$ top -p 4360,4358

或

$ top -p 4360 -p 4358

看起來很簡單，只須要使用 -p 列出全部須要的 PID，並使用逗號間隔或簡單的屢次使用 -p便可。
另外一種多是監測擁有特定用戶標識（UID）的進程。應對此需求，你可使用 -u 或 -U 選項。假設用戶「johndoe」的 UID 爲500，鍵入：

$ top -u johndoe

OR

$ top -u 500

或

$ top -U johndoe

結論是，你既能夠純使用用戶名，也可以使用數字 UID。「-u，-U？這二者不一樣？」是的。同多數其它 GNU 工具同樣，選項是大小寫敏感的。-U 意味着 Top 將會搜索有效的、真實的、被保存的以及文件系統的 UID 進行匹配，而 -u 僅匹配有效的用戶id。要知道，每個 *nix 進程在運行時都是用有效用戶標識（effective UID），而其中有些並不等同真實用戶標識。多數狀況是，對相似文件系統權限或操做系統功能這項的有效用戶標識感興趣的人將會檢查它，而不是 UID。
不一樣於 -p 僅用於命令行選項，-U 和 -u 均可以在交互模式中使用。同你猜想的同樣，鍵入‘U’或‘u’能夠依據用戶名過濾進程。一樣的規則依然適用，‘u’爲有效用戶標識，‘U’爲真實/有效/保存/文件系統用戶名。你將被要求鍵入用戶名或數字 UID。

翻譯於 2013/04/10 14:25

頂

3

C.快熟仍是緩慢更新？

在回答這個問題以前，讓咱們先簡單介紹一下，Top 是如何運行的。這裏，Strace 可以幫助你：

$ strace -o /tmp/trace.txt top -b -n 1

使用你偏心的文本編輯器打開 /tmp/trace.txt。你怎麼想？一次調用有太多的活要作了，反正我是這麼想的。Top 在每次遍歷中必作的工做之一就是打開不少文件，並解析其內容，能夠看看次數：

$ grep open( /tmp/hasil.txt | wc -l

舉例而言，個人 Linux 中，這個數量是304.仔細觀察就會發現，Top 遍歷 /proc 文件夾，以收集進程信息。/proc 自己是一個虛擬文件系統，意味着它並不是存在於真實硬盤之中，而是由 Linux 內核憑空建立，保存在內存中的。在文件夾中，如/proc/2097（2097爲 PID），Linux 內核將與之關聯的信息打印到此文件中，而這裏就是 Top 的消息來源。

同時試一下：

$ time top -b -n 1

這樣你就能瞭解到 Top 單輪工做有多快了。在個人系統中，大約爲0.5-0.6秒。看「real」字段，不是「user」或「system」字段，由於「real」字段反應了 Top 工做須要的總時間。

翻譯於 2013/04/10 14:42

頂

3

因此，有了這個認知以後，使用適度的更新間隔是明智的。基於文件系統訪問內存也是須要時間的。經驗法則是，對於多數用戶來講，1到3秒的間隔就足夠了。在命令行中使用-d，或在交互模式下按下「s」以設置。你可使用相似2.5,4.1這樣的小樹。

何時咱們須要快於1秒的更新？

時間段內須要更多的樣本。應對這點要求，最好使用批處理模式，並將標準輸出重定向到文件中，以便更好的分析。
你並不在乎 Top 消耗的額外CPU負荷。是的，雖然它很小，它依然須要負荷。若是你的 Linux 系統相對比較空閒，隨意使用短間隔，若是不是，最好爲重要的任務保留你的 CPU 時間。

一個減小 Top 工做的辦法是隻監測特定的幾個 PID。這樣，Top 無需遍歷 /proc 下全部的子文件夾。用戶名過濾呢？並不會變得更好。用戶名過濾會給Top帶來額外工做量，所以將其與短間隔聯合將會增長 CPU 負荷。

固然，當你須要強制更新時，按下 Space 鍵，Top 將會刷新統計。

翻譯於 2013/04/10 14:55

頂

3

D.咱們須要的字段

默認時，Top 啓動後會顯示下面的任務屬性：

字段	描述
PID :	進程 ID
USER :	有效用戶 ID
PR :	動態優先值
NI :	良好值，也被稱爲基本優先級
VIRT :	任務虛擬大小。包括進程的可執行二進制文件大小，數據區大小以及全部已加載的共享庫的大小。
RES :	目前任務內存消耗。存入交換分區的部分並不包含。
SHR :	一些內存區域可能由兩個或多個任務分享，此字段反應這些共享區域。例如共享庫以及 Sysv 共享內存。
S :	任務狀態
%CPU :	Top 屏幕更新時專用於運行任務的CPU 時間百分比。
%MEM :	任務當前內存消耗的百分比
TIME+ :	在任務啓動後消耗的總CPU時間。"+" sign means it is displayed with hundreth of a second granularity. 默認時，TIME/TIME+ 不會計入已經關閉的任務子進程。
COMMAND :	顯示程序名。

翻譯於 2013/04/10 15:19

頂

3

不止這些。下面我介紹一些你可能會用到的列：

列	描述
nFLT ('u'鍵)	進程啓動以來重大頁面錯誤(page fault)的個數。準確地說，頁面錯誤是因爲進程訪問它的地址空間內不存在的頁面引發的。「重大」的頁面錯誤是指內核須要訪問磁盤來使得該頁面有效。相反，小型頁面錯誤是指內核只須要在內存中分配頁面而不用讀磁盤。例如，假設程序ABC的大小爲8KB，頁面大小爲4KB。當程序讀進內存的時候，發生了兩次重大的頁面錯誤（2*4KB）。程序自己分配了8KB空間看成臨時數據。所以，還會有兩次小型頁面錯誤。 nFLT太高可能意味着：進程從磁盤讀取大量資源。The task is aggressively load some portions of its executable or library from the disk. 進程訪問了一個已經交換到磁盤的頁面。當進程第一次運行時，看到大量重大頁面錯誤很正常。下次運行的時候，因爲緩存已經分配好了，你極可能看到"0"次或者很小的 nFLT。可是，若是一個程序頻繁地觸發重大頁面錯誤，頗有多是你目前安裝的內存不夠那個程序使用。
nDRT ('v'鍵)	上次頁面寫入磁盤以來，髒頁面的數目。什麼是髒頁面？先看一點背景知識。你們都知道，Linux使用了緩存系統，因此從磁盤讀取的數據也會被緩存到內存中。這樣作的優勢是，後續的對這個磁盤塊的讀操做能夠直接從內存中取數據，於是速度更快。但這也是有代價的。若是緩衝區的內容被修改了，那麼就須要進行同步。所以，被更改的緩衝區（髒頁面）必需寫回到磁盤中。同步失敗則可能致使磁盤上的數據不一致。在負載不重的系統中，nDRT 一般小於10（大約估計）或者爲0。若是你的系統一般大於10，則有可能：進程正在往磁盤寫入大量數據。磁盤I/O常常跟不上緩衝區的速度。磁盤I/O擁塞，所以即便進程修改了很小部分文件，也必需等待一段時間才能完成同步。擁塞出如今不少進程同時訪問磁盤而緩存命中率低的狀況下（譯者注：FTP服務的典型狀況）。如今的話，(1) 不太可能出現，由於I/O速度愈來愈快，須要更少的CPU（DMA技術的出現）。因此 (2) 出現的機率更高。注意：在 2.6.x 內核中, 不知道爲何，這個列的值老是0。
P ('j'鍵)	上次使用的CPU。這個列只在SMP環境中有意義。這裏的SMP指超線程，多核或者多CPU架構。若是你只有一個CPU（不是多核，沒有超線程），這個列老是顯示0。在SMP系統中，即便這個列有幾回改變，也不要吃驚。這意味着，Linux 內核嘗試將你的進程移到另外一個負載更少的CPU。
CODE ('r'鍵) 和 DATA ('s'鍵)	CODE 只是反映了你程序代碼的大小，DATA反映了你數據段(棧，堆，變量，不包含共享庫) 的大小。單位都是KB。 DATA能夠顯示你的程序分配了多少內存。有時，也能夠用來協助分析內存泄漏。固然，你須要更好的工具，如使用 valgrind 來查看每次的內存分配。若是DATA不斷增加，則頗有可能出現了內存泄漏。注意：DATA, CODE, SHR, SWAP, VIRT, RES 都是使用頁面大小（Intel架構上爲4KB）來衡量。只讀數據段也包含在CODE的大小中，於是有時候CODE比實現的段要大。
SWAP ('p'鍵)	已經進行交換的進程內存映像大小。這個列有時很讓人疑惑：邏輯上，你可能指望這個列顯示你的程序其實是徹底進行交換，仍是部分交換了，交換了多少。可是事實上不是。即便"Swap used" 列顯示爲0，你仍然能夠很吃驚地發現全部進程的SWAP列都大於0。究竟是爲何呢？這是因爲 top 命令使用以下的計算公式： VIRT = SWAP + RES or equal SWAP = VIRT - RES 前面說過，VIRT 包含了進程的地址空間裏面的全部東西：內存中的，已經進行交換的，還沒有從磁盤讀取的。RES 表明了進程佔用的所有內存大小。因此，這裏的SWAP表明了已經進行交換的所有數據，以及還沒有從磁盤讀取的數據。不要被SWAP這個名字迷惑了，它表明的不僅是已經交換的數據。

翻譯於 2013/04/10 20:33

頂

3

要顯示以上的列，在交互模式下按 'f' 鍵，而後再按相應的鍵。按一下顯示指定的列，再按一下隱藏該列。要肯定當前顯示的是哪些列，只需看第一行的字母（在"Current Fields"的右邊）。大寫字母表示顯示了該列，小寫表示隱藏。你選好之後，按回車便可。

排序使用了相似的方法。按 'O' （大寫），而後再按相應的鍵。即便記不住那些按鍵也不要緊，top 會顯示出來。新的排序鍵將標上星號，相應的字母會變成大寫，很直觀。選好之後，記得按回車。

翻譯於 2013/04/10 20:41

頂

3

E.多視圖比單個視圖更好嗎？

在不一樣的狀況下，有時候咱們想監視不一樣的系統屬性。例如，你想同時監控CPU的百分比和CPU被全部任務消耗的時間。在另外一段時間，你想監控常駐內存和全部任務的總頁面故障。快速按‘F’鍵而後切換界面？我想這也太不明智了吧。

爲何不試試多視圖窗口模式呢？按‘A’(大寫)切換到多窗口界面。默認的，你將會看到4個不一樣的系列的字段組。每一個字段組有默認的標籤/名稱：

第一字段組: Def

第二字段組: Job

第三字段組: Mem

第四字段組: Usr

第一字段組就是你在單一視圖窗口所常見的組，而其他的組會被隱藏。內置多視圖窗口模式，全部可用的窗口經過按‘a’或者‘w’循環。注意，切換到其餘窗口時會改變活動窗口（也稱爲當前窗口）。假如你不肯定哪個是活動窗口的話，只須要看一下top展現的第一行（在當前時間字段的左邊）。另外一個改變活動窗口的方法是經過按‘G’緊跟着輸入數字（1到4）。

活動窗口是針對用戶輸入的，所以在開始幹活以前肯定選好了你偏好的界面。而後，你能夠在單一窗口模式下愛幹嗎幹嗎。在這種狀況你通常想自定義字段展現，那麼你只須要按‘f’而後開始自定義。

假如你認爲第四字段組太多的話，你只須要切換到字段組而後按‘-’隱藏。請注意，即便你隱藏了當前的字段組，那並不以意味着你同時改變了活動組。再次按‘-’的話，當前組就可見了。

若是你想操做多視圖窗口模式，再次按‘A’鍵。那樣也將使得活動組成爲了單一視圖窗口模式的新的字段組。

翻譯於 2013/04/11 22:53

頂

4

F. "個人Linux主機上怎麼會只有不多的空閒內存?"

有一樣的問題? 無論你在主板上增長多少內存，你都會很快發現空閒內存減小的很是迅速. 空閒內存算錯了? 不!

在回答這個以前, 先查看一下top命令頂部顯示的內存概要 (有可能你須要按 'm'來顯示出來). 在這裏，你能夠看到兩個區域: 緩衝（buffers）和緩存（cached）。 "緩衝（Buffers）" 表明有多少內存用來緩存磁盤塊 "緩存（Cached）" 有一點相似 "緩衝（Buffers）", 只是僅僅從文件讀取緩存頁面. 想透徹瞭解這部分,建議讀一下Linux內核的書好比Robert M.Love寫的《Linux Kernel Development》。

這足夠了解緩衝（buffers）和緩存（cached)表明系統緩存. 他們會根據linux內核機制動態增長或減小。

除去被緩存的消耗，程序和代碼一樣要佔據RAM. 因此，最終空閒內存顯示的是RAM中不被緩存和程序/代碼佔用的部分通常來講，你也能夠考慮緩存區域爲另外一部分「空閒」RAM，若是程序須要更多內存它會減小

從進程的角度來看，你可能想知道哪一個區域表明真實的內存消耗，VIRT（virtual memory usage ）區域? 固然不是! 回顧一下，這個區域表明了進程地址空間裏一切，包括相關的庫。閱讀top命令的源代碼和proc.txt (在內核代碼樹中的Documentation/filesystem 文件夾內), 個人結論是RSS字段是進程內存消耗的最好的描述.我說「最好的」是由於你能夠考慮它是近似而不是全部時間100%準確。