起因
最近我們在執行代碼更新的時候執行saltstack接收反饋信息特別慢，有時候還會出現卡住的現象，而我們的執行流程是通過saltstack-master 發送指令給阿里雲部署的enter機，由enter機去執行salt指令，
那麼我們就登錄到這臺阿里雲的enter機上，執行top發現機器負載很高，但是CPU、內存、磁盤IO、網絡IO使用率都不高
負載的狀態
1、uninterruptible （等待磁盤輸入輸出/不可中斷狀態）
2、nterruptible （等待鍵盤輸入輸出/可中斷狀態）
3、running（正在運行）
什麼是負載？
負載表示的是等待進程的平均數。在上面進程狀態變換過程中，除了running狀態，其他都是等待狀態，那麼其他狀態都會加入到負載等待進程中嗎？
事實證明，只有進程處於運行態（running）和不可中斷狀態（interruptible）纔會被加入到負載等待進程中，也就是下面這兩種情況的進程纔會表現爲負載的值
- 即便需要立即使用CPU，也還需等待其他進程用完CPU
- 即便需要繼續處理，也必須等待磁盤輸入輸出完成才能進行
什麼場景會造成CPU低而負載確很高呢？
通過上面的具體分析負載的意義就很明顯了，負載總結爲一句話就是：需要運行處理但又必須等待隊列前的進程處理完成的進程個數。具體來說，也就是如下兩種情況：
- 等待被授權予CPU運行權限的進程
- 等待磁盤I/O完成的進程
cpu低而負載高也就是說等待磁盤I/O完成的進程過多，就會導致隊列長度過大，這樣就體現到負載過大了，但實際是此時cpu被分配去執行別的任務或空閒，具體場景有如下幾種。
場景一：磁盤讀寫請求過多就會導致大量I/O等待
場景二：MySQL中存在沒有索引的語句或存在死鎖等情況
場景三：外接硬盤故障，常見有掛了NFS，但是NFS server故障
1、解決當前問題的思路
我們瞭解了系統負載的基本知識後，開始分析
1、系統負載其實就是運行態或者是不可中斷狀態下的進程反饋的狀態
2、當時考慮了負載高的問題可能出現的場景，那麼最有可能出問題的其實就是場景三,nfs導致負載高
3、那麼首先該阿里雲的enter機確實是有做nfs的掛載，是將華爲雲的一臺elk的機器，掛載到本地的/mnt目錄，而該機器正好前段時間被我們初始化了
4、出現該問題的原因主要是，在根目錄下ls的時候直接卡住，因爲nfs服務端已經掛掉了，那麼就會導致進程讀寫請求一直獲取不到資源，從而進程一直是不可中斷狀態，並且該ls 進程還特別多，導致cpu的上下文切換，造成負載很高。
2、開始處理故障
1.先把nfs掛載給卸載
umount /mnt2.重啓服務器
這個ls進程因爲是不可中斷狀態，那麼只能重啓機器
reboot
或
在雲的控制檯執行重啓操作3.重啓完成後即可完成恢復
uptime