咱們知道判斷一個系統的負載可使用top,uptime等命令去查看,它分別記錄了一分鐘、五分鐘、以及十五分鐘的系統平均負載緩存
例如個人某臺服務器:服務器
$ uptimeapp
09:50:21 up 200 days, 15:07, 1 user, load average: 0.27, 0.33, 0.37性能
大部分的人都認爲這個數字越小越好,其實有不少關聯的提示信息,今天看到這個好文,應該能夠給你們說清楚不少問題,轉一下:ui
原文連接: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averagesspa
你可能對於 Linux 的負載均值(load averages)已有了充分的瞭解。負載均值在 uptime 或者 top 命令中能夠看到,它們可能會顯示成這個樣子:線程
load average: 0.09, 0.05, 0.01orm
不少人會這樣理解負載均值:三個數分別表明不一樣時間段的系統平均負載(一分鐘、五 分鐘、以及十五分鐘),它們的數字固然是越小越好。數字越高,說明服務器的負載越 大,這也多是服務器出現某種問題的信號。blog
而事實不徹底如此,是什麼因素構成了負載均值的大小,以及如何區分它們目前的情況是 「好」仍是「糟糕」?何時應該注意哪些不正常的數值?隊列
回答這些問題以前,首先須要瞭解下這些數值背後的些知識。咱們先用最簡單的例子說明, 一臺只配備一塊單核處理器的服務器。
行車過橋
一隻單核的處理器能夠形象得比喻成一條單車道。設想下,你如今須要收取這條道路的過橋 費 — 忙於處理那些將要過橋的車輛。你首先固然須要瞭解些信息,例如車輛的載重、以及 還有多少車輛正在等待過橋。若是前面沒有車輛在等待,那麼你能夠告訴後面的司機經過。 若是車輛衆多,那麼須要告知他們可能須要稍等一會。
所以,須要些特定的代號表示目前的車流狀況,例如:
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,它還有一倍的資源能夠利用。
[NextPage]
多核與多處理器
先脫離下主題,咱們來討論下多核心處理器與多處理器的區別。從性能的角度上理解,一臺主 機擁有多核心的處理器與另臺擁有一樣數目的處理性能基本上能夠認爲是相差無幾。固然實際 狀況會複雜得多,不一樣數量的緩存、處理器的頻率等因素均可能形成性能的差別。
但即使這些因素形成的實際性能稍有不一樣,其實系統仍是以處理器的核心數量計算負載均值 。這使咱們有了兩個新的法則:
「有多少核心即爲有多少負荷」法則: 在多核處理中,你的系統均值不該該高於處理器核心的總數量。
「核心的核心」法則: 核心分佈在分別幾個單個物理處理中並不重要,其實兩顆四核的處理器 等於 四個雙核處理器 等於 八個單處理器。因此,它應該有八個處理器內核。
審視咱們本身
讓咱們再來看看 uptime 的輸出
~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
這是個雙核處理器,從結果也說明有不少的空閒資源。實際狀況是即使它的峯值會到 1.7,我也歷來沒有考慮過它的負載問題。
那麼,怎麼會有三個數字的確讓人困擾。咱們知道,0.6五、0.4二、0.36 分別說明上一分鐘、最後五分鐘以及最後十五分鐘的系統負載均值。那麼這又帶來了一個問題:
咱們以哪一個數字爲準?一分鐘?五分鐘?仍是十五分鐘?
其實對於這些數字咱們已經談論了不少,我認爲你應該着眼於五分鐘或者十五分鐘的平均數 值。坦白講,若是前一分鐘的負載狀況是 1.00,那麼仍能夠說明認定服務器狀況仍是正常的。 可是若是十五分鐘的數值仍然保持在 1.00,那麼就值得注意了(根據個人經驗,這時候你應 該增長的處理器數量了)。
那麼我如何得知個人系統裝備了多少核心的處理器?
在 Linux 下,可使用
cat /proc/cpuinfo
獲取你係統上的每一個處理器的信息。若是你只想獲得數字,那麼就使用下面的命令:
grep 'model name' /proc/cpuinfo | wc -l