Linux Load Average引數

首先如何獲取這個引數呢？
使用uptime就可以輸出，top命令也會提供其內容。
這三個數值代表一段時間內在執行佇列裡阻塞的程式數。系統提供的時間片段是load average:1min,5min,15min。

什麼是阻塞的程式呢？
阻塞的程式：一般在等待系統資源而不能繼續執行的程式。例如：
>>CPU
>>Disk I/O
>>Network I/O

空閒的cpu 就是0 load ，要是2.5就代表過載了150%

%us %sy表示cpu總共的處理時間。如果這兩個數經常是99%-100%說明你的cpu不行了。

如果%wa很高(80%) 說明cpu在等待I/O上花了很多時間，說明你的硬碟有點問題，要不是網路卡有點問題，還有可能程式試圖訪問非法的資料。執行ps faux可以查出錯誤。D-表示在等待，就是你的問題所在。

 

----------------------------------------------------  

參考文件：

我們知道判斷一個系統的負載可以使用top，uptime等命令去檢視，它分別記錄了一分鐘、五分鐘、以及十五分鐘的系統平均負載。
　　你可能對於 Linux 的負載均值(load averages)已有了充分的瞭解。負載均值在 uptime 或者 top 命令中可以看到，它們可能會顯示成這個樣子：
　　

Shell程式碼
  1. 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 的輸出
　　

Shell程式碼
  1. ~ $ uptime   
  2. 　　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 下，可以使用
　　

Shell程式碼 
  1. cat /proc/cpuinfo  


　　獲取你係統上的每個處理器的資訊。如果你只想得到數字，那麼就使用下面的命令：
　　

Shell程式碼
 
  1. grep 'model name' /proc/cpuinfo | wc -l