1 常用的 Load 分析方法
CPU高、Load高
- 通過 top 命令查找占用CPU最高的進程PID；
- 通過top -Hp PID查找占用CPU最高的線程TID;
- 對于JAVA程序，使用jstack打印線程堆棧信息；
- 通過printf %x tid打印出最消耗CPU線程的十六進制；
CPU低、Load高
產生的原因一句話總結就是：等待磁盤I/O完成的進程過多，導致進程隊列長度過大，但是CPU運行的進程卻很少，這樣就體現到負載過大了，cpu使用率低。
- 通過top命令查看CPU等待IO時間，即%wa；
- 通過IOStat -d -x -m 1 10查看磁盤IO情況；(安裝命令 yum install -y sysstat)
- 通過sar -n DEV 1 10查看網絡IO情況；
- 通過如下命令查找占用IO的程序；
ps -e -L h o state,cmd | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr
2 CPU高、Load高情況分析
- 使用vmstat 查看系統緯度的 CPU 負載；
- 使用 top 查看進程緯度的 CPU 負載；
2.1 使用 vmstat 查看系統緯度的 CPU 負載
可以通過 vmstat 從系統維度查看 CPU 資源的使用情況
格式：vmstat -n 1 -n 1 表示結果一秒刷新一次
[root@VM-1-14-centos ~]# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 250304 163472 2154300 0 0 1 16 0 4 1 0 98 0 0
0 0 0 250412 163472 2154332 0 0 0 0 937 1439 1 1 99 0 0
0 0 0 250428 163472 2154332 0 0 0 4 980 1329 0 0 100 0 0
0 0 0 250444 163472 2154332 0 0 0 0 854 1227 0 0 99 0 0
0 0 0 250444 163472 2154332 0 0 0 68 832 1284 0 1 99 1 0
0 0 0 250016 163472 2154332 0 0 0 0 929 1389 1 1 99 0 0
返回結果中的主要數據列說明：
- r：表示系統中 CPU 等待處理的線程。由于 CPU 每次只能處理一個線程，所以，該數值越大，通常表示系統運行越慢。
- b：表示阻塞的進程,這個不多說，進程阻塞，大家懂的。
- us：用戶CPU時間，我曾經在一個做加密解密很頻繁的服務器上，可以看到us接近100，r運行隊列達到80(機器在做壓力測試，性能表現不佳)。
- sy：系統CPU時間，如果太高，表示系統調用時間長，例如是IO操作頻繁。
- wa：IO 等待消耗的 CPU 時間百分比。該值較高時，說明 IO 等待比較嚴重，這可能磁盤大量作隨機訪問造成的，也可能是磁盤性能出現了瓶頸。
- id：處于空閑狀態的 CPU 時間百分比。如果該值持續為 0，同時 sy 是 us 的兩倍，則通常說明系統則面臨著 CPU 資源的短缺。
常見問題及解決方法：
- 如果 r 經常大于4，且id經常少于40，表示cpu的負荷很重。
- 如果pi，po長期不等于0，表示內存不足。
- 如果disk經常不等于0，且在b中的隊列大于3，表示io性能不好。
2.2 使用 top 查看進程緯度的 CPU 負載
可以通過 top 從進程緯度來查看其 CPU、內存等資源的使用情況。
top - 19:49:59 up 36 days, 23:15, 3 users, load average: 0.11, 0.04, 0.05
Tasks: 133 total, 1 running, 131 sleeping, 0 stopped, 1 zombie
%Cpu(s): 3.1 us, 3.1 sy, 0.0 ni, 93.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 3880188 total, 241648 free, 1320424 used, 2318116 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 2209356 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1793 MySQL 20 0 1608796 236708 9840 S 6.7 6.1 83:36.23 /usr/sbin/mysqld
1 root 20 0 125636 3920 2444 S 0.0 0.1 4:34.13 /usr/lib/systemd/systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.90 [kthreadd]
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/0:0H]
6 root 20 0 0 0 0 S 0.0 0.0 0:15.46 [ksoftirqd/0]
7 root rt 0 0 0 0 S 0.0 0.0 0:12.02 [migration/0]
默認界面上第三行會顯示當前 CPU 資源的總體使用情況，下方會顯示各個進程的資源占用情況。
可以直接在界面輸入大小字母 P，來使監控結果按 CPU 使用率倒序排列，進而定位系統中占用 CPU 較高的進程。最后，根據系統日志和程序自身相關日志，對相應進程做進一步排查分析，以判斷其占用過高 CPU 的原因。
3 CPU低、Load高
問題描述
linux 系統沒有業務程序運行，通過 top 觀察，類似如下圖所示，CPU 很空閑，但是 load average 卻非常高：
問題分析
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故障，那么就會導致進程讀寫請求一直獲取不到資源，從而進程一直是不可中斷狀態，造成負載很高。
處理辦法
- load average 是對 CPU 負載的評估，其值越高，說明其任務隊列越長，處于等待執行的任務越多。
- 出現此種情況時，可能是由于僵死進程導致的。可以通過指令ps -axjf查看是否存在 D 狀態進程。
- D 狀態是指不可中斷的睡眠狀態。該狀態的進程無法被 kill，也無法自行退出。只能通過恢復其依賴的資源或者重啟系統來解決。
等待 I/O 的進程通過處于 uninterruptible sleep 或 D 狀態；通過給出這些信息我們就可以簡單的查找出處在wait狀態的進程。
ps -e -L h o state,cmd | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr
作者：Honest1y
來源：https://juejin.cn/post/7016127914454286367
