轉自：http://bbs.linuxtone.org/thread-1684-1-1.html
top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源占用狀況，類似於Windows的任務管理器。下面詳細介紹它的使用方法。
| top - 01:06:48 up 1:22, 1 user, load average: 0.06, 0.60, 0.48 Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 191272k total, 173656k used, 17616k free, 22052k buffers Swap: 192772k total, 0k used, 192772k free, 123988k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1379 root 16 0 7976 2456 1980 S 0.7 1.3 0:11.03 sshd 14704 root 16 0 2128 980 796 R 0.7 0.5 0:02.72 top 1 root 16 0 1992 632 544 S 0.0 0.3 0:00.90 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 |
統計信息區前五行是系統整體的統計信息。第一行是任務隊列信息，同 uptime 命令的執行結果。其內容如下：
| 01:06:48 | 當前時間 |
| up 1:22 | 系統運行時間，格式為時:分 |
| 1 user | 當前登錄用戶數 |
| load average: 0.06, 0.60, 0.48 | 系統負載，即任務隊列的平均長度。 三個數值分別為 1分鍾、5分鍾、15分鍾前到現在的平均值。 |
第二、三行為進程和CPU的信息。當有多個CPU時，這些內容可能會超過兩行。內容如下：
| Tasks: 29 total | 進程總數 |
| 1 running | 正在運行的進程數 |
| 28 sleeping | 睡眠的進程數 |
| 0 stopped | 停止的進程數 |
| 0 zombie | 僵屍進程數 |
| Cpu(s): 0.3% us | 用戶空間占用CPU百分比 |
| 1.0% sy | 內核空間占用CPU百分比 |
| 0.0% ni | 用戶進程空間內改變過優先級的進程占用CPU百分比 |
| 98.7% id | 空閑CPU百分比 |
| 0.0% wa | 等待輸入輸出的CPU時間百分比 |
| 0.0% hi | |
| 0.0% si |
最后兩行為內存信息。內容如下：
| Mem: 191272k total | 物理內存總量 |
| 173656k used | 使用的物理內存總量 |
| 17616k free | 空閑內存總量 |
| 22052k buffers | 用作內核緩存的內存量 |
| Swap: 192772k total | 交換區總量 |
| 0k used | 使用的交換區總量 |
| 192772k free | 空閑交換區總量 |
| 123988k cached | 緩沖的交換區總量。 內存中的內容被換出到交換區，而后又被換入到內存，但使用過的交換區尚未被覆蓋， 該數值即為這些內容已存在於內存中的交換區的大小。 相應的內存再次被換出時可不必再對交換區寫入。 |
進程信息區統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。
| 序號 | 列名 | 含義 |
| a | PID | 進程id |
| b | PPID | 父進程id |
| c | RUSER | Real user name |
| d | UID | 進程所有者的用戶id |
| e | USER | 進程所有者的用戶名 |
| f | GROUP | 進程所有者的組名 |
| g | TTY | 啟動進程的終端名。不是從終端啟動的進程則顯示為 ? |
| h | PR | 優先級 |
| i | NI | nice值。負值表示高優先級，正值表示低優先級 |
| j | P | 最后使用的CPU，僅在多CPU環境下有意義 |
| k | %CPU | 上次更新到現在的CPU時間占用百分比 |
| l | TIME | 進程使用的CPU時間總計，單位秒 |
| m | TIME+ | 進程使用的CPU時間總計，單位1/100秒 |
| n | %MEM | 進程使用的物理內存百分比 |
| o | VIRT | 進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES |
| p | SWAP | 進程使用的虛擬內存中，被換出的大小，單位kb。 |
| q | RES | 進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA |
| r | CODE | 可執行代碼占用的物理內存大小，單位kb |
| s | DATA | 可執行代碼以外的部分(數據段+棧)占用的物理內存大小，單位kb |
| t | SHR | 共享內存大小，單位kb |
| u | nFLT | 頁面錯誤次數 |
| v | nDRT | 最后一次寫入到現在，被修改過的頁面數。 |
| w | S | 進程狀態。 D=不可中斷的睡眠狀態 R=運行 S=睡眠 T=跟蹤/停止 Z=僵屍進程 |
| x | COMMAND | 命令名/命令行 |
| y | WCHAN | 若該進程在睡眠，則顯示睡眠中的系統函數名 |
| z | Flags | 任務標志，參考 sched.h |
默認情況下僅顯示比較重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通過下面的快捷鍵來更改顯示內容。 更改顯示內容通過 f 鍵可以選擇顯示的內容。按 f 鍵之后會顯示列的列表，按 a-z 即可顯示或隱藏對應的列，最后按回車鍵確定。 按 o 鍵可以改變列的顯示順序。按小寫的 a-z 可以將相應的列向右移動，而大寫的 A-Z 可以將相應的列向左移動。最后按回車鍵確定。 按大寫的 F 或 O 鍵，然后按 a-z 可以將進程按照相應的列進行排序。而大寫的 R 鍵可以將當前的排序倒轉。 命令使用 1． 工具（命令）名稱 top 2．工具（命令）作用 顯示系統當前的進程和其他狀況；top是一個動態顯示過程,即可以通過用戶按鍵來不斷刷新當前狀態.如果在前台執行該命令,它將獨占前台,直到用戶終止該程序為止.比較准確的說,top命令提供了實時的對系統處理器的狀態監視.它將顯示系統中CPU最“敏感”的任務列表.該命令可以按CPU使用.內存使用和執行時間對任務進行排序；而且該命令的很多特性都可以通過交互式命令或者在個人定制文件中進行設定. 3．環境設置 在Linux下使用。 4．使用方法 4．1使用格式 top [-] [d] [p] [q] [c] [C] [S] [n] 4．2參數說明 d 指定每兩次屏幕信息刷新之間的時間間隔。當然用戶可以使用s交互命令來改變之。 p 通過指定監控進程ID來僅僅監控某個進程的狀態。 q該選項將使top沒有任何延遲的進行刷新。如果調用程序有超級用戶權限，那么top將以盡可能高的優先級運行。 S 指定累計模式 s 使top命令在安全模式中運行。這將去除交互命令所帶來的潛在危險。 i 使top不顯示任何閑置或者僵死進程。 c 顯示整個命令行而不只是顯示命令名 4.3其他 下面介紹在top命令執行過程中可以使用的一些交互命令。從使用角度來看，熟練的掌握這些命令比掌握選項還重要一些。這些命令都是單字母的，如果在命令行選項中使用了s選項，則可能其中一些命令會被屏蔽掉。 Ctrl+L 擦除並且重寫屏幕。 h或者? 顯示幫助畫面，給出一些簡短的命令總結說明。 k 終止一個進程。系統將提示用戶輸入需要終止的進程PID，以及需要發送給該進程什么樣的信號。一般的終止進程可以使用15信號；如果不能正常結束那就使用信號9強制結束該進程。默認值是信號15。在安全模式中此命令被屏蔽。 i 忽略閑置和僵死進程。這是一個開關式命令。 q 退出程序。 r 重新安排一個進程的優先級別。系統提示用戶輸入需要改變的進程PID以及需要設置的進程優先級值。輸入一個正值將使優先級降低，反之則可以使該進程擁有更高的優先權。默認值是10。 S 切換到累計模式。 s 改變兩次刷新之間的延遲時間。系統將提示用戶輸入新的時間，單位為s。如果有小數，就換算成m s。輸入0值則系統將不斷刷新，默認值是5 s。需要注意的是如果設置太小的時間，很可能會引起不斷刷新，從而根本來不及看清顯示的情況，而且系統負載也會大大增加。 f或者F 從當前顯示中添加或者刪除項目。 o或者O 改變顯示項目的順序。 l 切換顯示平均負載和啟動時間信息。 m 切換顯示內存信息。 t 切換顯示進程和CPU狀態信息。 c 切換顯示命令名稱和完整命令行。 M 根據駐留內存大小進行排序。 P 根據CPU使用百分比大小進行排序。 T 根據時間/累計時間進行排序。 W 將當前設置寫入~/.toprc文件中。這是寫top配置文件的推薦方法。 ----- 1、獲取cpu占用情況
[root@localhost utx86]# top -n 1 |grep Cpu Cpu(s): 1.9%us, 1.3%sy, 0.0%ni, 95.9%id, 0.6%wa, 0.1%hi, 0.2%si, 0.0%st
解釋：1.9%us是用戶占用cpu情況
1.3%sy,是系統占用cpu情況
2、獲得內存占用情況
[root@localhost utx86]# top -n 1 |grep Mem Mem: 2066240k total, 1515784k used, 550456k free, 195336k buffers
也許你在學習Linux操作系統，會遇到很多問題，這里為你講解Linux系統Load average負載的知識，你可能對於 Linux 的負載均值（load averages）已有了充分的了解。負載均值在 uptime 或者 top 命令中可以看到，它們可能會顯示成這個樣子：
load average: 0.09, 0.05, 0.01
很多人會這樣理解負載均值：三個數分別代表不同時間段的系統平均負載（一分鍾、五 分鍾、以及十五分鍾），它們的數字當然是越小越好。數字越高，說明服務器的負載越 大，這也可能是服務器出現某種問題的信號。
而事實不完全如此，是什么因素構成了負載均值的大小，以及如何區分它們目前的狀況是 “好”還是“糟糕”？什么時候應該注意哪些不正常的數值？
回答這些問題之前，首先需要了解下這些數值背后的些知識。我們先用最簡單的例子說明， 一台只配備一塊單核處理器的服務器。
行車過橋
一只單核的處理器可以形象得比喻成一條單車道。設想下，你現在需要收取這條道路的過橋 費 - 忙於處理那些將要過橋的車輛。你首先當然需要了解些信息，例如車輛的載重、以及還有多少車輛正在等待過橋。如果前面沒有車輛在等待，那么你可以告訴后面的司機通過。 如果車輛眾多，那么需要告知他們可能需要稍等一會。
因此，需要些特定的代號表示目前的車流情況，例如：
0.00 表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的，總而言之很通暢，過往的車輛可以絲毫不用等待的通過。
1.00 表示剛好是在這座橋的承受范圍內。 這種情況不算糟糕，只是車流會有些堵，不過這種情況可能會造成交通越來越慢。
超過 1.00，那么說明這座橋已經超出負荷，交通嚴重的擁堵。 那么情況有多糟糕？ 例如 2.00 的情況說明車流已經超出了橋所能承受的一倍，那么將有多余過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了，說明這座橋基本上已經快承受不了，還有超出橋負載兩倍多的車輛正在等待。
上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程 的實際時間。Unix 系統定義的進程運行時長為所有處理器內核的處理時間加上線程 在隊列中等待的時間。
和收過橋費的管理員一樣，你當然希望你的汽車（操作）不會被焦急的等待。所以，理想狀態 下，都希望負載平均值小於 1.00 。當然不排除部分峰值會超過 1.00，但長此以往保持這 個狀態，就說明會有問題，這時候你應該會很焦急。
“所以你說的理想負荷為 1.00 ？”
嗯，這種情況其實並不完全正確。負荷 1.00 說明系統已經沒有剩余的資源了。在實際情況中 ，有經驗的系統管理員都會將這條線划在 0.70：
“需要進行調查法則”： 如果長期你的系統負載在 0.70 上下，那么你需要在事情變得更糟糕之前，花些時間了解其原因。
“現在就要修復法則”：1.00 。 如果你的服務器系統負載長期徘徊於 1.00，那么就應該馬上解決這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。
“凌晨三點半鍛煉身體法則”：5.00。 如果你的服務器負載超過了 5.00 這個數字，那么你將失去你的睡眠，還得在會議中說明這情況發生的原因，總之千萬不要讓它發生。
那么多個處理器呢？我的均值是 3.00，但是系統運行正常！
哇喔，你有四個處理器的主機？那么它的負載均值在 3.00 是很正常的。
在多處理器系統中，負載均值是基於內核的數量決定的。以 100% 負載計算，1.00 表示單個處理器，而 2.00 則說明有兩個雙處理器，那么 4.00 就說明主機具有四個處理器。
回到我們上面有關車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道 1.00 情況中，說明這橋梁已經被車塞滿了。而在雙處理器系統中，這意味着多出了一倍的 負載，也就是說還有 50% 的剩余系統資源 - 因為還有另外條車道可以通行。
所以，單處理器已經在負載的情況下，雙處理器的負載滿額的情況是 2.00，它還有一倍的資源可以利用。
多核與多處理器
先脫離下主題，我們來討論下多核心處理器與多處理器的區別。從性能的角度上理解，一台主 機擁有多核心的處理器與另台擁有同樣數目的處理性能基本上可以認為是相差無幾。當然實際 情況會復雜得多，不同數量的緩存、處理器的頻率等因素都可能造成性能的差異。
但即便這些因素造成的實際性能稍有不同，其實系統還是以處理器的核心數量計算負載均值 。這使我們有了兩個新的法則：
“有多少核心即為有多少負荷”法則： 在多核處理中，你的系統均值不應該高於處理器核心的總數量。
“核心的核心”法則： 核心分布在分別幾個單個物理處理中並不重要，其實兩顆四核的處理器 等於 四個雙核處理器 等於 八個單處理器。所以，它應該有八個處理器內核。
審視我們自己
讓我們再來看看 uptime 的輸出
~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
這是個雙核處理器，從結果也說明有很多的空閑資源。實際情況是即便它的峰值會到 1.7，我也從來沒有考慮過它的負載問題。
那么，怎么會有三個數字的確讓人困擾。我們知道，0.65、0.42、0.36 分別說明上一分鍾、最后五分鍾以及最后十五分鍾的系統負載均值。那么這又帶來了一個問題：
我們以哪個數字為准？一分鍾？五分鍾？還是十五分鍾？
其實對於這些數字我們已經談論了很多，我認為你應該着眼於五分鍾或者十五分鍾的平均數 值。坦白講，如果前一分鍾的負載情況是 1.00，那么仍可以說明認定服務器情況還是正常的。 但是如果十五分鍾的數值仍然保持在 1.00，那么就值得注意了（根據我的經驗，這時候你應該增加的處理器數量了）。
那么我如何得知我的系統裝備了多少核心的處理器？
在Linux 下，可以使用
cat /proc/cpuinfo
獲取你系統上的每個處理器的信息。如果你只想得到數字，那么就使用下面的命令：
grep 'model name' /proc/cpuinfo | wc -l
Popularity: 11% [?]
以上就是Linux系統Load average負載的內容。