作者 | 蔣沖
來源 | 阿裡技術公衆号
雙十一壓測過程中，常見的問題之一就是load 飙高，通常這個時候業務上都有受影響，比如服務rt飙高，比如機器無法登入，比如機器上執行指令hang住等等。本文就來說說，什麼是load，load是怎麼計算的，什麼情況下load 會飙高，load飙高是不是必然業務受影響。
一 什麼是load
我們平時所講的load，其全稱是Linux system load averages ，即linux系統負載平均值。注意兩個關鍵詞：一個是“負載”，它衡量的是task（linux 核心中用于描述一個程序或者線程）對系統的需求（CPU、記憶體、IO等等），第二個關鍵詞是“平均”，它計算的是一段時間内的平均值，分别為 1、5 和 15 分鐘值。system load average由核心負載計算并記錄在/proc/loadavg 檔案中， 使用者态的工具（比如uptime，top等等）讀的都是這個檔案。
我們一般認為：
- 如果load接近0，意味着系統處于空閑狀态
- 如果 1min 平均值高于 5min 或 15min 平均值，則負載正在增加
- 如果 1min 平均值低于 5min 或 15min 平均值，則負載正在減少
- 如果它們高于系統 CPU 的數量，那麼系統很可能遇到了性能問題（視情況而定）
二 如何計算load
1 核心算法
坦白了不裝了，核心算法其實就是指數權重移動平均法（Exponential Weighted Moving Average，EMWA），簡單表示就是:
a1 = a0 factor + a (1 - factor)，其中a0是上一時刻的值，a1是目前時刻的值，factor是一個系數，取值範圍是[0,1]，a是目前時刻的某個名額采樣值。
為什麼要采用指數移動權重平均法？我個人了解
1、指數移動權重平均法，是指各數值的權重系數随時間呈指數式遞減，越靠近目前時刻的數值權重系數就越大，更能反映近期變化的趨勢；
2、計算時不需要儲存過去所有的數值，這對核心非常重要。
我們來看看，核心是怎麼計算load average的，以下簡稱load。
上面的指數移動平均公式，a1 = a0 e + a (1 - e)，具體到linux load的計算，a0是上一時刻的load，a1是目前時刻的load，e是一個常量系數，a 是目前時刻的active的程序/線程數量。
如上一節所述，linux 核心計算了三個load 值，分别是1分鐘/5分鐘/15分鐘 load 。計算這三個load 值時，使用了三個不同的常量系數e，定義如下：
#define EXP_1 1884 /* 1/exp(5sec/1min) */
#define EXP_5 2014 /* 1/exp(5sec/5min) */
#define EXP_15 2037 /* 1/exp(5sec/15min) */ 這三個系數是怎麼來的呢？公式如下：
- 1884 = 2048/(power(e,(5/(601)))) / e = 2.71828 */
- 2014 = 2048/(power(e,(5/(60*5))))
- 2037 = 2048/(power(e,(5/(60*15))))
其中e=2.71828，其實就是自然常數e，也叫歐拉數（Euler number）。
那為什麼是這麼個公式呢？其中，5是指每五秒采樣一次，60是指每分鐘60秒，1、5、15則分别是1分鐘、5分鐘和15分鐘。至于為什麼是2048和自然常數e，這裡涉及到定點計算以及其他一些數學知識，不是我們研究的重點，暫時不展開讨論。
我們看看核心中實際代碼：
/*
* a1 = a0 * e + a * (1 - e)
*/
static inline unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
{
unsigned long newload;
// FIXED_1 = 2048
newload = load * exp + active * (FIXED_1 - exp);
if (active >= load)
newload += FIXED_1-1;
return newload / FIXED_1;
} 就是一個很直覺的實作。上面代碼中，第一個參數就是上一時刻的load， 第二個參數就是常量系數，第三個參數是active的程序/線程數量（包括runnable 和 uninterruptible）。
2 計算流程
load的計算分為兩個步驟：
1、周期性地更新每個CPU上的rq裡的active tasks，包括runnable狀态和uninterruptible狀态的task，累加到一個全局變量calc_load_tasks。
2、周期性地計算 load，load的計算主要就是基于上述calc_load_tasks 變量。
第一個步驟，每個cpu都必須更新calc_load_tasks，但是第二個步驟隻由一個cpu來完成，這個cpu叫tick_do_timer_cpu，由它執行do_timer() -> calc_global_load()計算系統負載。
整體流程如下圖所示，在每個tick到來時（時鐘中斷），執行以下邏輯：
上圖中，棕色的calc_global_load_tick函數就是完成第一個步驟的，綠色的calc_global_load 是完成第二個步驟，藍色的calc_load 就是上一節中描述的核心算法。
這裡需要說明的是，calc_global_load 把計算出來的load 值放在一個全局的變量avenrun中，它的定義是unsigned long avenrun[3]，size 是3，用于存放1/5/15分鐘的load。 當檢視/proc/loadavg的時候，就是從這個avenrun數組中擷取資料。
三 load高常見原因
從上述load的計算原理可以看出，導緻load 飙高的原因，說簡單也簡單，無非就是runnable 或者 uninterruptible 的task 增多了。但是說複雜也複雜，因為導緻task進入uninterruptible狀态的路徑非常多（粗略統計，可能有400-500條路徑）。個人覺得，有些地方有點濫用這個狀态了。
本人基于多年的linux 核心開發和疑難問題排查經驗，總結了一些經驗，以飨讀者。
1 周期性飙高
曾經有些業務方遇到過load周期性飙高的現象，如果不是因為業務上确實有周期性的峰值，那麼大機率是踩中了核心計算load時的bug。這個bug和核心的load采樣頻率（ LOAD_FREQ）有關，具體細節不展開讨論。這個bug在ali2016，ali3000， ali4000中已經修複。
排除這個原因的話，可以接着檢視是否磁盤IO的原因。
2 IO原因
磁盤性能瓶頸
iostat -dx 1 可以檢視所有磁盤的IO 負載情況，當IOPS 或者 BW 高時，磁盤成為性能瓶頸，大量線程因為等待IO而處于uninterruptible 狀态，導緻load飙高。此時如果用vmstat 檢視，可能會觀察到 b 這一列的數值飙高， cpu iowait 飙高，/proc/stat檔案中的procs_blocked 數值飙高。
雲盤異常
雲盤是虛拟盤，IO路徑長而複雜，比較容易出問題。常見的異常是IO UTIL 100%，avgqu-sz 始終不為0，至少有1 。大家不要誤解，io util 100%并不意味着磁盤很忙，而隻意味着這個裝置的請求隊列裡在每次采樣時都發現有未完成的IO請求，是以當某種原因導緻IO丢失的話，雲盤就會出現UTIL 100%, 而ECS核心裡的jbd2 線程，業務線程也會被D住，導緻load 飙高。
JBD2 bug
JBD2是ext4 檔案系統的日志系統，一旦jbd2 核心線程由于bug hang住，所有的磁盤IO請求都會被阻塞，大量線程進入uninterruptible狀态，導緻load 飙高。
排除IO原因之後，接着可以檢視記憶體情況。
3 記憶體原因
記憶體回收
task 在申請記憶體的時候，可能會觸發記憶體回收，如果觸發的是直接記憶體回收，那對性能的傷害很大。目前task 會被阻塞直到記憶體回收完成，新的請求可能會導緻task數量增加（比如HSF線程池擴容），load 就會飙高。 可以通過tsar --cpu --mem --load -i1 -l 檢視，一般會觀察到sys cpu 飙高，cache 突降等現象。
記憶體帶寬競争
大家可能隻聽說過IO帶寬，網絡帶寬，很少注意記憶體帶寬。其實記憶體除了在容量次元有瓶頸，在帶寬層面也有瓶頸，隻是這個名額普通的工具觀察不了。我們開發的aprof 工具可以觀察記憶體帶寬競争，在雙十一保障期間在混部環境大顯神威。
4 鎖
通常是核心某些路徑上的spin_lock會成為瓶頸，尤其是網絡的收發包路徑上。可以用perf top -g 檢視到spin_lock的熱點， 然後根據函數位址找到核心的源碼。 伴随的現象可能有sys 飙高，softirq 飙高。
另外，采用mutex_lock進行并發控制的路徑上，一旦有task 拿着lock 不釋放，其他的task 就會以TASK_UNINTERRUPTIBLE的狀态等待，也會引起load飙高。但是如果這把鎖不在關鍵路徑上，那麼對業務可能就沒啥影響。
5 user CPU
有些情況下load飙高是業務的正常表現，此時一般表現為user cpu 飙高，vmstat 看到 r 這一列升高，tsar --load -i1 -l 看到runq 升高，檢視proc/pid/schedstats 可能會看到第二個數字也就是sched delay 會增加很快。
四 根因分析大招
1 RUNNABLE 型load飙高分析
如上所述，這種情況，通常是由于業務量的增加導緻的，屬于正常現象，但也有是業務代碼bug導緻的，比如長循環甚至死循環。但無論哪一種，一般都可以通過熱點分析或者叫on cpu分析找到原因。on cpu分析的工具比較多，比如perf，比如阿裡自研的ali-diagnose perf等等。
2 UNINTERRUPTIBLE型load飙高分析
所謂UNINTERRUPTIBLE，就是意味着在等，是以我們隻要找到等在哪裡，就基本找到原因了。
查找UNINTERRUPTIBLE狀态程序
UNINTERRUPTIBLE，通常也稱為D狀态，下文就用D狀态來描述。有一些簡單的工具可以統計目前D狀态程序的數量， 稍微複雜一點的工具可以把D狀态程序的調用鍊也就是stack輸出。這類工具一般都是從核心提供的proc 檔案系統取數。
檢視/proc/${pid}/stat 以及/proc/${pid}/task/${pid}/stat 檔案，可以判斷哪些task 處于D狀态，如下所示：
第三個字段就是task的狀态。然後再檢視/proc/${pid}/stack 檔案就可以知道task 等在哪裡。如：
但有時候，D狀态的task 不固定，這會導緻抓不到D狀态或者抓到stack的不準确。這時候，就得上另一個終極大招，延遲分析。
延遲分析
延遲分析需要深入核心内部，在核心路徑上埋點取數。是以這類工具的本質是核心probe，包括systemtap，kprobe，ebpf等等。但是probe 技術必須結合知識和經驗才能打造成一個實用的工具。阿裡自研的ali-diagnose可以進行各種delay分析，irq_delay, sys_delay, sched_delay, io_delay, load-monitor。
五 總結
linux 核心是一個複雜的并發系統，各子產品關系錯綜複雜。但是就load 而言，隻要從runnable task和 uninterruptible task兩個次元進行分析，總能找到根源。
大資料Hive教程精講
點選這裡檢視