引用: http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html
CPU 時間片 為了提高程序執行效率，大家在很多應用中都採用了多線程模式，這樣可以將原來的序列化執行變為並行執行，任務的分解以及並行執行能夠極大地提高程序的運行效率。但這都是代碼級別的表現，而硬件是如何支持的呢？那就要靠 CPU 的時間片模式來說明這一切。程序的任何指令的執行往往都會要競爭 CPU 這個最寶貴的資源，不論你的程序分成了多少個線程去執行不同的任務，他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單 CPU 的情況。下面兩圖描述了時間片模式和非時間片模式下的線程執行的情況： 在圖一中可以看到，任何線程如果都排隊等待 CPU 資源的獲取，那麼所謂的多線程就沒有任何實際意義。圖二中的 CPU Manager 只是我虛擬的一個角色，由它來分配和管理 CPU 的使用狀況，此時多線程將會在運行過程中都有機會得到 CPU 資源，也真正實現了在單 CPU 的情況下實現多線程並行處理。 多 CPU 的情況只是單 CPU 的擴展，當所有的 CPU 都滿負荷運作的時候，就會對每一個 CPU 採用時間片的方式來提高效率。 在 Linux 的內核處理過程中，每一個進程默認會有一個固定的時間片來執行命令（默認為 1/100 秒），這段時間內進程被分配到 CPU ，然後獨占使用。如果使用完，同時未到時間片的規定時間，那麼就主動放棄 CPU 的佔用，如果到時間片尚未完成工作，那麼 CPU 的使用權也會被收回，進程將會被中斷掛起等待下一個時間片。 CPU 利用率和Load Average 的區別 壓力測試不僅需要對業務場景的並髮用戶等壓力參數作模擬，同時也需要在壓力測試過程中隨時關注機器的性能情況，來確保壓力測試的有效性。當服務器長期處於一種超負荷的情況下運行，所能接收的壓力並不是我們所認為的可接受的壓力。就好比項目經理在給一個人估工作量的時候，每天都讓這個人工作 12 個小時，那麼所製定的項目計劃就不是一個合理的計劃，那個人遲早會垮掉，而影響整體的項目進度。 CPU 利用率在過去常常被我們這些外行認為是判斷機器是否已經到了滿負荷的一個標準，看到 50%-60% 的使用率就認為機器就已經壓到了臨界了。CPU 利用率，顧名思義就是對於 CPU 的使用狀況，這是對一個時間段內 CPU 使用狀況的統計，通過這個指標可以看出在某一個時間段內 CPU 被佔用的情況，如果被佔用時間很高，那麼就需要考慮 CPU 是否已經處於超負荷運作，長期超負荷運作對於機器本身來說是一種損害，因此必須將 CPU 的利用率控制在一定的比例下，以保證機器的正常運作。 Load Average 是 CPU 的 Load ，它所包含的信息不是 CPU 的使用率狀況，而是在一段時間內 CPU 正在處理以及等待 CPU 處理的進程數之和的統計信息，也就是 CPU 使用隊列的長度的統計信息。為什麼要統計這個信息，這個信息的對於壓力測試的影響究竟是怎麼樣的，那就通過一個類比來解釋 CPU 利用率和 Load Average 的區別以及對於壓力測試的指導意義。 我們將 CPU 就類比為電話亭，每一個進程都是一個需要打電話的人。現在一共有 4 個電話亭（就好比我們的機器有 4 核），有 10 個人需要打電話。現在使用電話的規則是管理員會按照順序給每一個人輪流分配 1 分鐘的使用電話時間，如果使用者在 1 分鐘內使用完畢，那麼可以立刻將電話使用權返還給管理員，如果到了 1 分鐘電話使用者還沒有使用完畢，那麼需要重新排隊，等待再次分配使用。 上圖中對於使用電話的用戶又作了一次分類， 1min 的代表這些使用者佔用電話時間小於等於 1min ， 2min 表示使用者佔用電話時間小於等於 2min ，以此類推。根據電話使用規則， 1min 的用戶只需要得到一次分配即可完成通話，而其他兩類用戶需要排隊兩次到三次。 電話的利用率 = sum (active use cpu time)/period 每一個分配到電話的使用者使用電話時間的總和去除以統計的時間段。這裡需要注意的是是使用電話的時間總和 (sum(active use cpu time)) ，這與占用時間的總和 (sum(occupy cpu time)) 是有區別的。（例如一個用戶得到了一分鐘的使用權，在 10 秒鐘內打了電話，然後去查詢號碼本花了 20 秒鐘，再用剩下的 30 秒打了另一個電話，那麼佔用了電話 1 分鐘，實際只是使用了 40 秒） 電話的 Average Load 體現的是在某一統計時間段內，所有使用電話的人加上等待電話分配的人一個平均統計。 電話利用率的統計能夠反映的是電話被使用的情況，當電話長期處於被使用而沒有的到足夠的時間休息間歇，那麼對於電話硬件來說是一種超負荷的運作，需要調整使用頻度。而電話 Average Load 卻從另一個角度來展現對於電話使用狀態的描述， Average Load 越高說明對於電話資源的競爭越激烈，電話資源比較短缺。對於資源的申請和維護其實也是需要很大的成本，所以在這種高 Average Load 的情況下電話資源的長期“熱競爭”也是對於硬件的一種損害。 低利用率的情況下是否會有高 Load Average 的情況產生呢？理解佔有時間和使用時間就可以知道，當分配時間片以後，是否使用完全取決於使用者，因此完全可能出現低利用率高 Load Average 的情況。由此來看，僅僅從 CPU 的使用率來判斷 CPU 是否處於一種超負荷的工作狀態還是不夠的，必須結合 Load Average 來全局的看 CPU 的使用情況和申請情況。 所以回過頭來再看測試部對於 Load Average 的要求，在我們機器為 8 個 CPU 的情況下，控制在 10 Load 左右，也就是每一個 CPU 正在處理一個請求，同時還有 2 個在等待處理。看了看網上很多人的介紹一般來說 Load 簡單的計算就是 2* CPU 個數減去 1-2 左右（這個只是網上看來的，未必是一個標準）。 補充幾點： 1 ．對於 CPU 利用率和 CPU Load Average 的結果來判斷性能問題。首先低 CPU 利用率不表明 CPU 不是瓶頸，競爭 CPU 的隊列長期保持較長也是 CPU 超負荷的一種表現。對於應用來說可能會去花時間在 I/O,Socket 等方面，那麼可以考慮是否後這些硬件的速度影響了整體的效率。 這裡最好的樣板範例就是我在測試中發現的一個現象： SIP 當前在處理過程中，為了提高處理效率，將控制策略以及計數信息都放置在 Memcached Cache 裡面，當我將 ??Memcached Cache 配置擴容一倍以後， CPU 的利用率以及 Load 都有所下降，其實也就是在處理任務的過程中，等待 Socket 的返回對於 CPU 的競爭也產生了影響。 2 ．未來多 CPU 編程的重要性。現在服務器的 CPU 都是多 CPU 了，我們的服務器處理能力已經不再按照摩爾定律來發展。就我上面提到的電話亭場景來看，對於三種不同時間需求的用戶來說，採用不同的分配順序，我們可看到的 Load Average 就會有不同。假設我們統計 Load 的時間段為 2 分鐘，如果將電話分配的順序按照： 1min 的用戶， 2min 的用戶， 3min 的用戶來分配，那麼我們的 Load Average 將會最低，採用其他順序將會有不同的結果。所以未來的多 CPU 編程可以更好的提高 CPU 的利用率，讓程序跑的更快。 以上所提到的內容未必都是很準確或者正確，如果有任何的偏差也請大家指出，可以糾正一些不清楚的概念。
引用 : http://blog.donews.com/zzw45/archive/2005/11/14/626449.aspx
在Linux系統中，uptime、w、top等命令都會有系統平均負載load average的輸出，那麼什麼是系統平均負載呢？ 系統平均負載被定義為在特定時間間隔內運行隊列中的平均進程樹。如果一個進程滿??足以下條件則其就會位於運行隊列中： - 它沒有在等待I/O操作的結果 - 它沒有主動進入等待狀態(也就是沒有調用'wait') - 沒有被停止(例如：等待終止) 例如： [root@www2 init.d]# uptime 7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94 命令輸出的最後內容表示在過去的1、5、15分鐘內運行隊列中的平均進程數量。 一般來說只要每個CPU的當前活動進程數不大於3那麼系統的性能就是良好的，如果每個CPU的任務數大於5，那麼就表示這台機器的性能有嚴重問題。對於上面的例子來說，假設系統有兩個CPU，那麼其每個CPU的當前任務數為：8.13/2=4.065。這表示該系統的性能是可以接受的。
引用 : http://www.linuxeden.com/html/develop/20060829/24483.html
/proc/stat/ : 包含了所有CPU活動的信息，該文件中的所有值都是從系統啟動開始累計到當前時刻。 /proc/loadavg : 該文件中的所有值都是從系統啟動開始累計到當前時刻。該文件只給出了所有CPU的集合信息，不能該出每個CPU的信息。
引用 : http://en.wikipedia.org/wiki/Load_(computing)
For example, one can interpret a load average of "1.73 0.60 7.98" on a single-CPU system as: during the last minute, the system was overloaded by 73% on average (1.73 runnable processes, so that 0.73 processes had to wait for a turn for a single CPU system on average). during the last 5 minutes, the CPU was idling 40% of the time on average. during the last 15 minutes, the system was overloaded 698% on average (7.98 runnable processes, so that 6.98 processes had to wait for a turn for a single CPU system on average).
http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
http://www.gracecode.com/posts/2973.html
load average 如果為 1，代表 交通是順的，但如果為 2.5 代表超過了 150%
sysstat 套件包含了以下指令可以監看系統負載
1. iostat
iostat 2 : 每兩秒報告每個 partition 的 IO 存取，等於 iostat -d 2
tps : 每秒傳輸總量
Blk_read/s : 每秒讀取 block 數量
Blk_wrtn/s : 每秒寫入 block 數量
Blk_read : 讀總數
Blk_wrtn : 寫總數
iostat -c 2 : CPU Usages
iostat -k 2 : 用 kb 計算，-m 就是 mb
2. mpstat
3. sar
sar -q 2 100 : 每 2 秒顯示，共 100 行，報告佇列長度
runq-sz : 等待的佇列數
plist-sz : 全部行程數
ldavg-1 : 最近一分鐘
ldavg-5 : 過去五分鐘
ldavg-15 : 過去十五分鐘
sar -u 2 100 : 報告 CPU usages
sar -b 2 100 : 報告 I/O 存取
tps : 等於 rtps + wtps，每秒傳輸總量
rtps : 每秒 read 的 request 數量
wtps : 每秒 write 的 request 數量
bread/s : 每秒對 block 的 read 數量
bwrtn/s : 每秒對 write 的 read 數量
procps 套件包含了以下指令
vmstat top top -b -n1 | head -n30 : 單次列出前 30 行 w uptime tload
留言