理解Linux中Load_average負載

負載均值在 uptime 或者 top 命令中可以看到,它們可能會顯示成這個樣子:load average: 0.09, 0.05, 0.01

很多人會這樣理解負載均值:三個數分別代表不同時間段的系統平均負載(一分鐘、五 分鐘、以及十五分鐘),它們的數字當然是越小越好。數字越高,說明服務器的負載越 大,這也可能是服務器出現某種問題的信號。

而事實不完全如此,是什么因素構成了負載均值的大小,以及如何區分它們目前的狀況是 “好”還是“糟糕”?什么時候應該注意哪些不正常的數值?回答這些問題之前,首先需要了解下這些數值背后的些知識。我們先用最簡單的例子說明, 一臺只配備一塊單核處理器的服務器。

行車過橋

一只單核的處理器可以形象得比喻成一條單車道。設想下,你現在需要收取這條道路的過橋 費 - 忙于處理那些將要過橋的車輛。你首先當然需要了解些信息,例如車輛的載重、以及還有多少車輛正在等待過橋。如果前面沒有車輛在等待,那么你可以告訴后面的司機通過。 如果車輛眾多,那么需要告知他們可能需要稍等一會。因此,需要些特定的代號表示目前的車流情況,例如:

0.00:表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的,總而言之很通暢,過往的車輛可以絲毫不用等待的通過。

1.00: 表示剛好是在這座橋的承受范圍內。 這種情況不算糟糕,只是車流會有些堵,不過這種情況可能會造成交通越來越慢。

1.00 超過 1.00:那么說明這座橋已經超出負荷,交通嚴重的擁堵。 那么情況有多糟糕? 例如 2.00 的情況說明車流已經超出了橋所能承受的一倍,那么將有多余過橋一倍的車輛正在焦急的等待。

3.00:的話情況就更不妙了,說明這座橋基本上已經快承受不了,還有超出橋負載兩倍多的車輛正在等待。

上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程的實際時間。Unix 系統定義的進程運行時長為所有處理器內核的處理時間加上線程在隊列中等待的時間。

和收過橋費的管理員一樣,你當然希望你的汽車(操作)不會被焦急的等待。所以,理想狀態 下,都希望負載平均值小于 1.00 。當然不排除部分峰值會超過 1.00,但長此以往保持這 個狀態,就說明會有問題,這時候你應該會很焦急。

所以你說的理想負荷為 1.00 ?

嗯,這種情況其實并不完全正確。負荷 1.00 說明系統已經沒有剩余的資源了。在實際情況中 ,有經驗的系統管理員都會將這條線劃在 0.70:

1) 需要進行調查法則:0.70。如果長期你的系統負載在 0.70 上下,那么你需要在事情變得更糟糕之前,花些時間了解其原因。

2) 現在就要修復法則:1.00 。 如果你的服務器系統負載長期徘徊于 1.00,那么就應該馬上解決這個問題。否則,你將半夜接到你上司的電話,這可不是件令人愉快的事情。

3) 凌晨三點半鍛煉身體法則:5.00。 如果你的服務器負載超過了 5.00 這個數字,那么你將失去你的睡眠,還得在會議中說明這情況發生的原因,總之千萬不要讓它發生。

那么多個處理器呢?我的均值是 3.00,但是系統運行正常

哇喔,你有四個處理器的主機?那么它的負載均值在 3.00 是很正常的。

在多處理器系統中,負載均值是基于內核的數量決定的。以 100% 負載計算,1.00 表示單個處理器,而 2.00 則說明有兩個雙處理器,那么 4.00 就說明主機具有四個處理器。

回到我們上面有關車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道 1.00 情況中,說明這橋梁已經被車塞滿了。而在雙處理器系統中,這意味著多出了一倍的 負載,也就是說還有 50% 的剩余系統資源 - 因為還有另外條車道可以通行。

所以,單處理器已經在負載的情況下,雙處理器的負載滿額的情況是 2.00,它還有一倍的資源可以利用。

多核與多處理器

我們來討論下多核心處理器與多處理器的區別。從性能的角度上理解,一臺主機擁有多核心的處理器與另臺擁有同樣數目的處理性能基本上可以認為是相差無幾。當然實際情況會復雜得多,不同數量的緩存、處理器的頻率等因素都可能造成性能的差異。

但即便這些因素造成的實際性能稍有不同,其實系統還是以處理器的核心數量計算負載均值 。這使我們有了兩個新的法則:

1) 有多少核心即為有多少負荷法則:在多核處理中,你的系統均值不應該高于處理器核心的總數量。

2) 核心的核心法則:核心分布在分別幾個單個物理處理中并不重要,其實兩顆四核的處理器等于四個雙核處理器等于八個單處理器。所以,它應該有八個處理器內核。

讓我們再來看看 uptime 的輸出:

這是個4核處理器,從結果也說明有很多的空閑資源。實際情況是即便它的峰值會到 2.8,我也從來沒有考慮過它的負載問題。那么,怎么會有三個數字的確讓人困擾。我們知道,0.65、0.42、0.36 分別說明上一分鐘、最后五分鐘以及最后十五分鐘的系統負載均值。那么這又帶來了一個問題:我們以哪個數字為準?一分鐘?五分鐘?還是十五分鐘?

其實對于這些數字我們已經談論了很多,我認為你應該著眼于五分鐘或者十五分鐘的平均數值。坦白講,如果前一分鐘的負載情況是 1.00,那么仍可以說明認定服務器情況還是正常的。 但是如果十五分鐘的數值仍然保持在 1.00,那么就值得注意了(根據我的經驗,這時候你應該增加的處理器數量了)。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,517評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,087評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,521評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,493評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,207評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,603評論 1 325
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,624評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,813評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,364評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,110評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,305評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,874評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,532評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,953評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,209評論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,033評論 3 396
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,268評論 2 375

推薦閱讀更多精彩內容