$ uptime
11:12:26 up 3:44, 4 users, load average: 0.38, 0.31, 0.19
系統平均負載被定義為在特定時間間隔內執行佇列中的平均程式樹。如果一個程式滿足以下條件則其就會位於執行佇列中：
-
它沒有在等待I/O操作的結果
-
它沒有主動進入等待狀態(也就是沒有呼叫'wait')
-
沒有被停止(例如：等待終止)
上面的輸出，load average後面分別是1分鐘、5分鐘、15分鐘的負載情況。資料是每隔5秒鐘檢查一次活躍的程式數，然後根據這個數值算出來的。如果這個數除以CPU 的數目，結果高於5的時候就表明系統在超負荷運轉了。
Linux系統Load average負載詳細解釋 我們知道判斷一個系統的負載可以使用top，uptime等命令去檢視，它分別記錄了一分鐘、五分鐘、以及十五分鐘的系統平均負載
例如我的某臺伺服器：
$ uptime
09:50:21 up 200 days, 15:07, 1 user, load average: 0.27, 0.33, 0.37
大部分的人都認為這個數字越小越好，其實有很多關聯的提示資訊，今天看到這個好文，應該可以給大家說清楚很多問題，轉一下：
你可能對於 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 這個數字，那麼你將失去你的睡眠，還得在會議中說明這情況發生的原因，總之千萬不要讓它發生。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26613085/viewspace-1402424/，如需轉載，請註明出處，否則將追究法律責任。