- 它沒有在等待I/O操作的結果
- 它沒有主動進入等待狀態(也就是沒有調用'wait')
- 沒有被停止(例如：等待終止)
SIP的第四期結束了，因為控制策略的豐富，早先的的壓力測試結果已經無法反映在高並發和高壓力下SIP的運行狀況，因此需要重新作壓力測試。跟在測試人員後面做了快一周的壓力測試，壓力測試的報告也正式出爐，本來也就算是告一段落，但第二天測試人員說要修改報告，由於這次作壓力測試的同學是第一次作，有一個指標沒有注意，因此需要修改幾個測試結果。那個沒有注意的指標就是load
average，他和我一樣開始只是注意了CPU，內存的使用狀況，而沒有太注意這個指標，這個指標與他們通常的限制（10左右）有差別。重新測試的結果由於這個指標被要求壓低，最後的報告顯然不如原來的好看。自己也沒有深入過壓力測試，但是覺得不搞明白對將來機器配置和擴容都會有影響，因此去問了DBA和SA，得到的結果相差很大，看來不得不自己去找找問題的根本所在了。
通過下面的幾個部分的了解，可以一步一步的找出Load Average在壓力測試中真正的作用。
CPU時間片為了提高程序執行效率，大家在很多應用中都采用了多線程模式，這樣可以將原來的序列化執行變為並行執行，任務的分解以及並行執行能夠極大地提高程序的運行效率。但這都是代碼級別的表現，而硬件是如何支持的呢？那就要靠CPU的時間片模式來說明這一切。程序的任何指令的執行往往都會要競爭CPU這個最寶貴的資源，不論你的程序分成了多少個線程去執行不同的任務，他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單CPU的情況。下面兩圖描述了時間片模式和非時間片模式下的線程執行的情況：
圖 1 非時間片線程執行情況
圖 2 非時間片線程執行情況
在圖一中可以看到，任何線程如果都排隊等待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分鐘電話使用者還沒有使用完畢，那麼需要重新排隊，等待再次分配使用。
圖 3 電話使用場景
上圖中對於使用電話的用戶又作了一次分類，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左右（這個只是網上看來的，未必是一個標准）。
關於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，但長此以往保持這 個狀態，就說明會有問題，這時候你應該會很焦急。
“需要進行調查法則”： 如果長期你的系統負載在 0.70 上下，那麼你需要在事情變得更糟糕之前，花些時間了解其原因。
“現在就要修復法則”：1.00 。 如果你的服務器系統負載長期徘徊於 1.00，那麼就應該馬上解決這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。
“凌晨三點半鍛煉身體法則”：5.00。 如果你的服務器負載超過了 5.00 這個數字，那麼你將失去你的睡眠，還得在會議中說明這情況發生的原因，總之千萬不要讓它發生。
在多處理器系統中，負載均值是基於內核的數量決定的。以 100% 負載計算，1.00 表示單個處理器，而 2.00 則說明有兩個雙處理器，那麼 4.00 就說明主機具有四個處理器。
回到我們上面有關車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那麼在單車道 1.00 情況中，說明這橋梁已經被車塞滿了。而在雙處理器系統中，這意味著多出了一倍的 負載，也就是說還有 50% 的剩余系統資源 -- 因為還有另外條車道可以通行。
所以，單處理器已經在負載的情況下，雙處理器的負載滿額的情況是 2.00，它還有一倍的資源可以利用。
但即便這些因素造成的實際性能稍有不同，其實系統還是以處理器的核心數量計算負載均值 。這使我們有了兩個新的法則：
“有多少核心即為有多少負荷”法則： 在多核處理中，你的系統均值不應該高於處理器核心的總數量。
“核心的核心”法則： 核心分布在分別幾個單個物理處理中並不重要，其實兩顆四核的處理器
等於 四個雙核處理器 等於 八個單處理器。所以，它應該有八個處理器內核。
~ $ 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 -l1 load average 的定義
在特定時間間隔內運行隊列中的平均進程數。
2 w 命令查看 load average
load average: 1.00, 0.7, 0.8
1分鐘 5 分鐘 15分鐘
其中分別代表1分鐘，5分鐘，15分鐘系統的平均負載。則三個數字，會重點觀察5分鐘，15分鐘對應的數值，這反映了系統一段時間的工作狀況。此值低於1.00為正常（注釋1），長時間等於1.00需要引起注意，大於5.00說明系統出現嚴重的 cpu資源不足，隨時可能出問題，屬於critical級別。
3 load average 與cpu 利用率的區別
3.1 cpu 利用率的查看，top命令
3.2 什麼是cpu利用率
單位時間內進程使用cpu時間的百分比
3.3 load average 與cpu 利用率的區別
load average=占用cpu進程+排隊進程數
cpu利用率=單位時間內進程使用cpu時間的百分比
load average 表示的是cpu還有多少件事情要處理，cpu利用率表示：一個進程別cpu處理時，占用時間片（注釋2）的比值。
注釋1：這裡指的是1個cpu所對應的負載值。
注釋2：在Linux的內核處理過程中，每一個進程默認會有一個固定的時間片來執行命令（默認為1/100秒），這段時間稱為時間片。
=========================================================================================================================
在Linux系統中，我們一般使用uptime命令查看（w命令和top命令也行）。（另外，它們在蘋果公司的Mac電腦上也適用。）
你在終端窗口鍵入uptime，系統會返回一行信息。
這行信息的後半部分，顯示"load average"，它的意思是"系統的平均負荷"，裡面有三個數字，我們可以從中判斷系統負荷是大還是小。
為什麼會有三個數字呢？你從手冊中查到，它們的意思分別是1分鐘、5分鐘、15分鐘內系統的平均負荷。
如果你繼續看手冊，它還會告訴你，當CPU完全空閒的時候，平均負荷為0；當CPU工作量飽和的時候，平均負荷為1。
那麼很顯然，"load average"的值越低，比如等於0.2或0.3，就說明電腦的工作量越小，系統負荷比較輕。
但是，什麼時候能看出系統負荷比較重呢？等於1的時候，還是等於0.5或等於1.5的時候？如果1分鐘、5分鐘、15分鐘三個值不一樣，怎麼辦？
二、一個類比判斷系統負荷是否過重，必須理解load average的真正含義。下面，我根據"Understanding
Linux CPU Load"這篇文章，嘗試用最通俗的語言，解釋這個問題。
首先，假設最簡單的情況，你的電腦只有一個CPU，所有的運算都必須由這個CPU來完成。
那麼，我們不妨把這個CPU想象成一座大橋，橋上只有一根車道，所有車輛都必須從這根車道上通過。（很顯然，這座橋只能單向通行。）
系統負荷為0，意味著大橋上一輛車也沒有。
系統負荷為0.5，意味著大橋一半的路段有車。
系統負荷為1.0，意味著大橋的所有路段都有車，也就是說大橋已經"滿"了。但是必須注意的是，直到此時大橋還是能順暢通行的。
系統負荷為1.7，意味著車輛太多了，大橋已經被占滿了（100%），後面等著上橋的車輛為橋面車輛的70%。以此類推，系統負荷2.0，意味著等 待上橋的車輛與橋面的車輛一樣多；系統負荷3.0，意味著等待上橋的車輛是橋面車輛的2倍。總之，當系統負荷大於1，後面的車輛就必須等待了；系統負荷越 大，過橋就必須等得越久。
CPU的系統負荷，基本上等同於上面的類比。大橋的通行能力，就是CPU的最大工作量；橋梁上的車輛，就是一個個等待CPU處理的進程（process）。
如果CPU每分鐘最多處理100個進程，那麼系統負荷0.2，意味著CPU在這1分鐘裡只處理20個進程；系統負荷1.0，意味著CPU在這1分鐘 裡正好處理100個進程；系統負荷1.7，意味著除了CPU正在處理的100個進程以外，還有70個進程正排隊等著CPU處理。
為了電腦順暢運行，系統負荷最好不要超過1.0，這樣就沒有進程需要等待了，所有進程都能第一時間得到處理。很顯然，1.0是一個關鍵值，超過這個值，系統就不在最佳狀態了，你要動手干預了。
三、系統負荷的經驗法則1.0是系統負荷的理想值嗎？
不一定，系統管理員往往會留一點余地，當這個值達到0.7，就應當引起注意了。經驗法則是這樣的：
當系統負荷持續大於0.7，你必須開始調查了，問題出在哪裡，防止情況惡化。
當系統負荷持續大於1.0，你必須動手尋找解決辦法，把這個值降下來。
當系統負荷達到5.0，就表明你的系統有很嚴重的問題，長時間沒有響應，或者接近死機了。你不應該讓系統達到這個值。
四、多處理器上面，我們假設你的電腦只有1個CPU。如果你的電腦裝了2個CPU，會發生什麼情況呢？
2個CPU，意味著電腦的處理能力翻了一倍，能夠同時處理的進程數量也翻了一倍。
還是用大橋來類比，兩個CPU就意味著大橋有兩根車道了，通車能力翻倍了。
所以，2個CPU表明系統負荷可以達到2.0，此時每個CPU都達到100%的工作量。推廣開來，n個CPU的電腦，可接受的系統負荷最大為n.0。
五、多核處理器芯片廠商往往在一個CPU內部，包含多個CPU核心，這被稱為多核CPU。
在系統負荷方面，多核CPU與多CPU效果類似，所以考慮系統負荷的時候，必須考慮這台電腦有幾個CPU、每個CPU有幾個核心。然後，把系統負荷除以總的核心數，只要每個核心的負荷不超過1.0，就表明電腦正常運行。
怎麼知道電腦有多少個CPU核心呢？
"cat /proc/cpuinfo"命令，可以查看CPU信息。"grep -c 'model name' /proc/cpuinfo"命令，直接返回CPU的總核心數。
六、最佳觀察時長最後一個問題，"load average"一共返回三個平均值----1分鐘系統負荷、5分鐘系統負荷，15分鐘系統負荷，----應該參考哪個值？
如果只有1分鐘的系統負荷大於1.0，其他兩個時間段都小於1.0，這表明只是暫時現象，問題不大。
如果15分鐘內，平均系統負荷大於1.0（調整CPU核心數之後），表明問題持續存在，不是暫時現象。所以，你應該主要觀察"15分鐘系統負荷"，將它作為電腦正常運行的指標。
==========================================
上文來自：http://blog.csdn.net/evenness/article/details/7658221