原因總結

產生的原因一句話總結就是：等待磁碟I/O完成的程序過多，導致程序佇列長度過大，但是cpu執行的程序卻很少，這樣就體現到負載過大了，cpu使用率低。
下面內容是具體的原理分析：在分析負載為什麼高之前先介紹下什麼是負載、多工作業系統、程序排程等相關概念。

什麼是負載

什麼是負載：負載就是cpu在一段時間內正在處理以及等待cpu處理的程序數之和的統計資訊，也就是cpu使用佇列的長度統計資訊，這個數字越小越好（如果超過CPU核心*0.7就是不正常）
負載分為兩大部分：CPU負載、IO負載
例如，假設有一個進行大規模科學計算的程式，雖然該程式不會頻繁地從磁碟輸入輸出，但是處理完成需要相當長的時間。因為該程式主要被用來做計算、邏輯判斷等處理，所以程式的處理速度主要依賴於cpu的計算速度。此類cpu負載的程式稱為“計算密集型程式”。
還有一類程式，主要從磁碟儲存的大量資料中搜索找出任意檔案。這個搜尋程式的處理速度並不依賴於cpu，而是依賴於磁碟的讀取速度，也就是輸入輸出（input/output,I/O）.磁碟越快，檢索花費的時間就越短。此類I/O負載的程式，稱為“I/O密集型程式”。

什麼是多工作業系統

Linux作業系統能夠同時處理幾個不同名稱的任務。但是同時執行多個任務的過程中，cpu和磁碟這些有限的硬體資源就需要被這些任務程式共享。即便很短的時間間隔內，需要一邊在這些任務之間進行切換到一邊進行處理，這就是多工。
執行中的任務較少的情況下，系統並不是等待此類切換動作的發生。但是當任務增加時，例如任務A正在CPU上執行計算，接下來如果任務B和C也想進行計算，那麼就需要等待CPU空閒。也就是說，即便是執行處理某任務，也要等到輪到他時才能執行，此類等待狀態就表現為程式執行延遲。

11:48:16 up 34 days, 34 min, 1 user, load average: 9.25, 11.39, 11.11
USER TTY FROM

Load average從左邊起依次是過去1分鐘、5分鐘、15分鐘內，單位時間的等待任務數，也就是表示平均有多少任務正處於等待狀態。在load average較高的情況下，這就說明等待執行的任務較多，因此輪到該任務執行的等待時間就會出現較大的延遲，即反映了此時負載較高。

程序排程

什麼是程序排程：
程序排程也被一些人稱為cpu上下文切換意思是：CPU切換到另一個程序需要儲存當前程序的狀態並恢復另一個程序的狀態：當前執行任務轉為就緒（或者掛起、中斷）狀態，另一個被選定的就緒任務成為當前任務。程序排程包括儲存當前任務的執行環境，恢復將要執行任務的執行環境。
在linux核心中，每一個程序都存在一個名為“程序描述符”的管理表。該程序描述符會調整為按照優先順序降序排序，已按合理的順序執行程序（任務）。這個調整即為程序排程器的工作。
排程器劃分並管理程序的狀態，如：
等待分配cpu資源的狀態。
等待磁碟輸入輸出完畢的狀態。

下面在說一下程序的狀態區別：
程序5大狀態說明

執行態（running）

只要cpu空閒，任何時候都可以執行

可中斷睡眠（interruptible）

為恢復時間無法預測的長時間等待狀態。如，來自於鍵盤裝置的輸入。

不可中斷睡眠:（uninterruptible）

主要為短時間時的等待狀態。例如磁碟輸入輸出等待。被IO阻塞的程序

就緒態（runnable）

響應暫停訊號而執行的中斷狀態。

僵死態（zombie）

程序都是由父程序建立，並銷燬；在父程序沒有銷燬其子程序，被銷燬的時候，其子程序由於沒有父程序被銷燬，就會轉變為僵死態。

下面舉例來說明程序狀態轉變：
這裡有三個程序A、B、C同時執行。首先，每個程序在生成後都是可執行狀態，也就是running狀態的開始，而不是現在執行狀態，由於在linux核心中無法區別正在執行的狀態和可執行的等待狀態，下面將可執行狀態和正在執行狀態都稱為running狀態。
程序A：running
程序B：running
程序C：running

running的三個程序立即成為排程物件。此時，假設排程器給程序A分配了CPU的執行許可權。
程序A：running （正在執行）
程序B：running
程序C：running

程序A分配了CPU，所以程序A開始處理。程序B和C則在此等待程序A遷出CPU。假設程序A進行若干計算之後，需要從磁碟讀取資料。那麼在A發出讀取磁碟資料的請求之後，到請求資料到達之前，將不進行任何工作。此狀態稱為“因等待I/O操作結束而被阻塞”。在I/O完成處理前，程序A就一直處於等待中，就會轉為不可中斷睡眠狀態（uninterruptible），並不使用CPU。於是排程器檢視程序B和程序C的優先順序計算結果，將CPU執行許可權交給優先順序較高的一方。這裡假設程序B的優先順序高於程序C。
程序A：uninterruptible （等待磁碟輸入輸出/不可中斷狀態）
程序B：running （正在執行）
程序C：running

程序B剛開始執行，就需要等待使用者的鍵盤輸入。於是B進入等待使用者鍵盤輸入狀態，同樣被阻塞。結果就變成了程序A和程序B都是等待輸出，執行程序C。這時程序A和程序B都是等待狀態，但是等待磁碟輸入輸出和等待鍵盤輸入為不同的狀態。等待鍵盤輸入是無限期的事件等待，而讀取磁碟則是必須短時間內完成的事件等待，這是兩種不同的等待狀態。各程序狀態如下所示：
程序A：uninterruptible （等待磁碟輸入輸出/不可中斷狀態）
程序B：interruptible （等待鍵盤輸入輸出/可中斷狀態）
程序C：running （正在執行）

這次假設程序C在執行的過程中，程序A請求的資料從磁碟到達了緩衝裝置。緊接著硬碟對核心發起中斷訊號，核心知道磁碟讀取完成，將程序A恢復為可執行狀態。
程序A：running （正在執行）
程序B：interruptible （等待鍵盤輸入輸出/可中斷狀態）
程序C：running （正在執行）

此後程序C也會變為某種等待狀態。如CPU的佔用時間超出了上限、任務結束、進入I/O等待。一旦滿足這些條件，排程器就可以完成從程序C到程序A的程序狀態切換。

負載的意義：

負載表示的是“等待程序的平均數”。在上面的程序狀態變換過程中，除了running狀態，其他都是等待狀態，那麼其他狀態都會加入到負載等待程序中嗎？
事實證明，只有程序處於執行態（running）和不可中斷狀態（uninterruptible）才會被加入到負載等待程序中，也就是下面這兩種情況的程序才會表現為負載的值。
即便需要立即使用CPU，也還需等待其他程序用完CPU
即便需要繼續處理，也必須等待磁碟輸入輸出完成才能進行

下面描述一種直觀感受的場景說明為什麼只有執行態（running）和不可中斷狀態（uninterruptible）才會被加入負載。

如：在很佔用CPU資源的處理中，例如在進行動畫編碼的過程中，雖然想進行其他相同型別的處理，結果系統反映卻變得很慢，還有從磁碟讀取大量資料時，系統的反映也同樣會變的很慢。但是另一方面，無論有多少等待鍵盤輸入輸出操作的程序，也不會讓系統響應變慢。
什麼場景會造成CPU低而負載確很高呢？
通過上面的具體分析負載的意義就很明顯了，負載總結為一句話就是：需要執行處理但又必須等待佇列前的程序處理完成的程序個數。具體來說，也就是如下兩種情況：
等待被授權予CPU執行許可權的程序
等待磁碟I/O完成的程序

cpu低而負載高也就是說等待磁碟I/O完成的程序過多，就會導致佇列長度過大，這樣就體現到負載過大了，但實際是此時cpu被分配去執行別的任務或空閒，具體場景有如下幾種。

場景一：磁碟讀寫請求過多就會導致大量I/O等待

上面說過，cpu的工作效率要高於磁碟，而程序在cpu上面執行需要訪問磁碟檔案，這個時候cpu會向核心發起呼叫檔案的請求，讓核心去磁碟取檔案，這個時候會切換到其他程序或者空閒，這個任務就會轉換為不可中斷睡眠狀態。當這種讀寫請求過多就會導致不可中斷睡眠狀態的程序過多，從而導致負載高，cpu低的情況。

場景二：MySQL中存在沒有索引的語句或存在死鎖等情況

我們都知道MySQL的資料是儲存在硬碟中，如果需要進行sql查詢，需要先把資料從磁碟載入到記憶體中。當在資料特別大的時候，如果執行的sql語句沒有索引，就會造成掃描表的行數過大導致I/O阻塞，或者是語句中存在死鎖，也會造成I/O阻塞，從而導致不可中斷睡眠程序過多，導致負載過大。
具體解決方法可以在MySQL中執行show full processlist命令檢視執行緒等待情況，把其中的語句拿出來進行優化。

場景三：外接硬碟故障，常見有掛了NFS，但是NFS server故障

比如我們的系統掛載了外接硬碟如NFS共享儲存，經常會有大量的讀寫請求去訪問NFS儲存的檔案，如果這個時候NFS Server故障，那麼就會導致程序讀寫請求一直獲取不到資源，從而程序一直是不可中斷狀態，造成負載很高。

作者：wangfs
連結：https://www.jianshu.com/p/347afe9ba9ee
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。