一、load average
top命令中load average顯示的是最近1分鍾、5分鍾和15分鍾的系統平均負載。系統平均負載表示
系統平均負載被定義為在特定時間間隔內運行隊列中(在CPU上運行或者等待運行多少進程)的平均進程數。如果一個進程滿足以下條件則其就會位於運行隊列中：
- 它沒有在等待I/O操作的結果
- 它沒有主動進入等待狀態(也就是沒有調用’wait’)
- 沒有被停止(例如：等待終止)
Update：在Linux中，進程分為三種狀態，一種是阻塞的進程blocked process，一種是可運行的進程runnable process，另外就是正在運行的進程running process。當進程阻塞時，進程會等待I/O設備的數據或者系統調用。
進程可運行狀態時，它處在一個運行隊列run queue中，與其他可運行進程爭奪CPU時間。 系統的load是指正在運行running one和准備好運行runnable one的進程的總數。比如現在系統有2個正在運行的進程，3個可運行進程，那么系統的load就是5。load average就是一定時間內的load數量。
一般來說只要每個CPU的當前活動進程數不大於3那么系統的性能就是良好的，如果每個CPU的任務數大於5，那么就表示這台機器的性能有嚴重問題。對於上面的例子來說，假設系統有兩個CPU，那么其每個CPU的當前任務數為：8.13/2=4.065。這表示該系統的性能是可以接受的。
在Linux系統中，uptime、w、top等命令都會有系統平均負載load average的輸出
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
二、top
在理解了load average各個值的含義后，可以用top命令來了解系統的整理狀態，關注重量變量的時刻變化。為此還需了解以下這些變量。
-
下面詳細介紹它的使用方法。
-
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 緩沖的交換區總量。
-
內存中的內容被換出到交換區，而后又被換入到內存，但使用過的交換區尚未被覆蓋，
-
該數值即為這些內容已存在於內存中的交換區的大小。
-
相應的內存再次被換出時可不必再對交換區寫入。
-
-
進程信息區統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。
-
列名 含義
-
PID 進程id
-
PPID 父進程id
-
RUSER Real user name
-
UID 進程所有者的用戶id
-
USER 進程所有者的用戶名
-
GROUP 進程所有者的組名
-
TTY 啟動進程的終端名。不是從終端啟動的進程則顯示為 ?
-
PR 優先級
-
NI nice值。負值表示高優先級，正值表示低優先級
-
P 最后使用的CPU，僅在多CPU環境下有意義
-
%CPU 上次更新到現在的CPU時間占用百分比
-
TIME 進程使用的CPU時間總計，單位秒
-
TIME+ 進程使用的CPU時間總計，單位1/100秒
-
%MEM 進程使用的物理內存百分比
-
VIRT 進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES
-
SWAP 進程使用的虛擬內存中，被換出的大小，單位kb。
-
RES 進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA
-
CODE 可執行代碼占用的物理內存大小，單位kb
-
DATA 可執行代碼以外的部分(數據段+棧)占用的物理內存大小，單位kb
-
SHR 共享內存大小，單位kb
-
nFLT 頁面錯誤次數
-
nDRT 最后一次寫入到現在，被修改過的頁面數。
-
S 進程狀態。
-
D=不可中斷的睡眠狀態
-
R=運行
-
S=睡眠
-
T=跟蹤/停止
-
Z=僵屍進程
-
COMMAND 命令名/命令行
-
WCHAN 若該進程在睡眠，則顯示睡眠中的系統函數名
-
Flags 任務標志，參考 sched.h
三、調試
在查看了top命令所顯示的狀態后，需要依據其來做優化，但top命令顯示的只是表象，所以我們可以通過iostat或者vmstat命令進一步的觀察。
3.1：查看系統負載vmstat
-
vmstat
-
procs -------memory-------- ----swap-- -----io---- --system-- ----cpu----
-
r b swpd free buff cache si so bi bo in cs us sy id wa
-
0 0 100152 2436 97200 289740 0 1 34 45 99 33 0 0 99 0
procs
r 列表示運行和等待cpu時間片的進程數，如果長期大於1，說明cpu不足，需要增加cpu。
b 列表示在等待資源的進程數，比如正在等待I/O、或者內存交換等。
cpu 表示cpu的使用狀態
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，但是如果長期大於50%，需要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這里us + sy的參考值為80%，如果us+sy 大於 80%說明可能存在CPU不足。
wa 列顯示了IO等待所占用的CPU時間的百分比。這里wa的參考值為30%，如果wa超過30%，說明IO等待嚴重，這可能是磁盤大量隨機訪問造成的，也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)。
id 列顯示了cpu處在空閑狀態的時間百分比
system 顯示采集間隔內發生的中斷數
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
memory
swpd 切換到內存交換區的內存數量(k表示)。如果swpd的值不為0，或者比較大，比如超過了100m，只要si、so的值長期為0，系統性能還是正常
free 當前的空閑頁面列表中內存數量(k表示)
buff 作為buffer cache的內存數量，一般對塊設備的讀寫才需要緩沖。
cache: 作為page cache的內存數量，一般作為文件系統的cache，如果cache較大，說明用到cache的文件較多，如果此時IO中bi比較小，說明文件系統效率比較好。
swap
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
IO
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
這里我們設置的bi+bo參考值為1000，如果超過1000，而且wa值較大應該考慮均衡磁盤負載，可以結合iostat輸出來分析。
3.2：查看磁盤負載iostat
每隔2秒統計一次磁盤IO信息，直到按Ctrl+C終止程序，-d 選項表示統計磁盤信息， -k 表示以每秒KB的形式顯示，-t 要求打印出時間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤IO負載狀況提供了關於自從系統啟動以來的統計信息。隨后的每一次輸出則是每個間隔之間的平均IO負載狀況。
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，因為每扇區大小為512字節。(需要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
idle小於70% IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)
另外還可以參考
一般:
svctm < await (因為同時等待的請求的等待時間被重復計算了)，
svctm的大小一般和磁盤性能有關:CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await: await的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。
如果 svctm 比較接近 await，說明I/O 幾乎沒有等待時間；
如果 await 遠大於 svctm，說明 I/O隊列太長，應用得到的響應時間變慢，
如果響應時間超過了用戶可以容許的范圍，這時可以考慮更換更快的磁盤，調整內核 elevator算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標，但由於 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子.(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎么決定該去哪個交款台呢? 首當是看排的隊人數，5個人總比20人要快吧?除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個采購了一星期食品的大媽，那么可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5分鍾前還人滿為患的收款台，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鍾里所做的事情比排隊要有意義(不過我還沒發現什么事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
r/s+w/s 類似於交款人的總數
平均隊列長度(avgqu-sz)類似於單位時間里平均排隊人的個數
平均服務時間(svctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O數據(avgrq-sz)類似於平均每人所買的東西多少
I/O 操作率 (%util)類似於收款台前有人排隊的時間比例。
我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，為什么? 因為發出的 I/O 請求太多 (每秒鍾約 29 個)，假設這些請求是同時發出的，那么平均等待時間可以這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + ... + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來並不均勻，大部分時間 I/O 是空閑的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間里 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23，而iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35，為什么?! 因為 iostat 中有 bug，avgqu-sz值應為 2.23，而不是 22.35。