一、什麼是系統平均負載
uptime、w、top等命令都會有系統負載load average的輸出，系統平均負載被定義爲在特定時間間隔內運行隊列中的平均進程數，包括可運行狀態和不可中斷狀態的平均進程數，也就是活躍進程數。它和cpu使用率沒有直接的關係
二、衡量系統性能
如果系統平均負載的數值除以CPU的數目高於5，系統在超負荷運轉了。一般來說每個cpu的當前進程數不大於3那麼系統還可以(這個與另一份資料有衝突，待考究TODO)
三、行車過橋（引用）
一隻單核的處理器可以形象得比喻成一條單車道。設想下，你現在需要收取這條道路的過橋 費 - 忙於處理那些將要過橋的車輛。你首先當然需要了解些信息，例如車輛的載重、以及還有多少車輛正在等待過橋。如果前面沒有車輛在等待，那麼你可以告訴後面的司機通過。 如果車輛衆多，那麼需要告知他們可能需要稍等一會。
因此，需要些特定的代號表示目前的車流情況，例如：
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，它還有一倍的資源可以利用。
“有多少核心即爲有多少負荷”法則： 在多核處理中，你的系統均值不應該高於處理器核心的總數量。
四、自我總結
這次是因爲公司服務器出了點問題，自己對這塊又不熟悉，系統負載那些指數含義不太懂，所以去搜集了相關資料學習了一下。才明白公司服務器這個負載均衡是沒有什麼問題，即使這些資料有衝突，還是得找找相關的問題出現在哪~有時間要看看更爲準確的資料，先mark一下。從本次的學習當中知道了
- 1、系統平均負載與cpu沒有直接聯繫，數值與活躍進程直接關係
- 2、系統負載看cpu數，負載值除以cpu，沒有大於1肯定好的，服務器出了問題，先看負載，看看哪些進程在消耗資源等等（負載這步）
PS：
1、歡迎訪問我的個人站點：小白求學進階
2、微信公衆號：
參考資料