CPU飆高，系統性能問題如何排查？-有解無憂

簡介：壓測時或多或少都收到過CPU或者Load高的告警，如果是單機偶發性的，經常會認為是“宿主機搶占導致的”，那事實是否真是如此呢？是什么引起了這些指標的飆高？網路、磁盤還是高并發？有什么工具可以定位？TOP、PS還是vmstat？CPU高&Load高和CPU低&Load高，不同的表征又代表著什么？

一背景知識

LINUX行程狀態

LINUX 2.6以后的內核中，行程一般存在7種基礎狀態：D-不可中斷睡眠、R-可執行、S-可中斷睡眠、T-暫停態、t-跟蹤態、X-死亡態、Z-僵尸態，這幾種狀態在PS命令中有對應解釋，

D (TASK_UNINTERRUPTIBLE)，不可中斷睡眠態，顧名思義，位于這種狀態的行程處于睡眠中，并且不允許被其他行程或中斷(異步信號)打斷，因此這種狀態的行程，是無法使用kill -9殺死的(kill也是一種信號)，除非重啟系統(沒錯，就是這么頭硬)，不過這種狀態一般由I/O等待(比如磁盤I/O、網路I/O、外設I/O等)引起，出現時間非常短暫，大多很難被PS或者TOP命令捕獲(除非I/O HANG死)，SLEEP態行程不會占用任何CPU資源，

R (TASK_RUNNING)，可執行態，這種狀態的行程都位于CPU的可執行佇列中，正在運行或者正在等待運行，即不是在上班就是在上班的路上，

S (TASK_INTERRUPTIBLE)，可中斷睡眠態，不同于D，這種狀態的行程雖然也處于睡眠中，但是是允許被中斷的，這種行程一般在等待某事件的發生（比如socket連接、信號量等），而被掛起，一旦這些時間完成，行程將被喚醒轉為R態，如果不在高負載時期，系統中大部分行程都處于S態，SLEEP態行程不會占用任何CPU資源，

T&t (__TASK_STOPPED & __TASK_TRACED)，暫停or跟蹤態，這種兩種狀態的行程都處于運行停止的狀態，不同之處是暫停態一般由于收到SIGSTOP、SIGTSTP、SIGTTIN、SIGTTOUT四種信號被停止，而跟蹤態是由于行程被另一個行程跟蹤引起(比如gdb斷點），暫停態行程會釋放所有占用資源，

Z (EXIT_ZOMBIE), 僵尸態，這種狀態的行程實際上已經結束了，但是父行程還沒有回收它的資源（比如行程的描述符、PID等），僵尸態行程會釋放除行程入口之外的所有資源，

X (EXIT_DEAD), 死亡態，行程的真正結束態，這種狀態一般在正常系統中捕獲不到，

Load Average & CPU使用率

談到系統性能，Load和CPU使用率是最直觀的兩個指標，那么這兩個指標是怎么被計算出來的呢？是否能互相等價呢？

Load Average

不少人都認為，Load代表正在CPU上運行&等待運行的行程數，即

但Linux系統中，這種描述并不完全準確，

以下為Linux內核原始碼中Load Average計算方法，可以看出來，因此除了可執行態行程，不可中斷睡眠態行程也會被一起納入計算，即：

602staticunsignedlongcount_active_tasks(void)
603 {
604structtask_struct*p;
605unsignedlongnr=0;
606607read_lock(&tasklist_lock);
608for_each_task(p) {
609if ((p->state==TASK_RUNNING610 (p->state&TASK_UNINTERRUPTIBLE)))
611nr+=FIXED_1;
612 }
613read_unlock(&tasklist_lock);
614returnnr;
615 }
......
625staticinlinevoidcalc_load(unsignedlongticks)
626 {
627unsignedlongactive_tasks; /* fixed-point */628staticintcount=LOAD_FREQ;
629630count-=ticks;
631if (count<0) {
632count+=LOAD_FREQ;
633active_tasks=count_active_tasks();
634CALC_LOAD(avenrun[0], EXP_1, active_tasks);
635CALC_LOAD(avenrun[1], EXP_5, active_tasks);
636CALC_LOAD(avenrun[2], EXP_15, active_tasks);
637 }
638 }

在前文 Linux行程狀態中有提到過，不可中斷睡眠態的行程(TASK_UNINTERRUTED)一般都在進行I/O等待，比如磁盤、網路或者其他外設等待，由此我們可以看出，Load Average在Linux中體現的是整體系統負載，即CPU負載 + Disk負載 + 網路負載 + 其余外設負載，并不能完全等同于CPU使用率(這種情況只出現在Linux中，其余系統比如Unix，Load還是只代表CPU負載)，

CPU使用率

CPU的時間分片一般可分為4大類：用戶行程運行時間 - User Time, 系統內核運行時間 - System Time, 空閑時間 - Idle Time, 被搶占時間 - Steal Time，除了Idle Time外，其余時間CPU都處于作業運行狀態，

通常而言，我們泛指的整體CPU使用率為User Time 和 Systime占比之和(例如tsar中CPU util)，即：

為了便于定位問題，大多數性能統計工具都將這4類時間片進一步細化成了8類，如下為TOP對CPU時間片的分類，

us：用戶行程空間中未改變過優先級的行程占用CPU百分比
sy：內核空間占用CPU百分比
ni：用戶行程空間內改變過優先級的行程占用CPU百分比
id：空閑時間百分比
wa：空閑&等待I/O的時間百分比
hi：硬中斷時間百分比
si：軟中斷時間百分比
st：虛擬化時被其余VM竊取時間百分比

這8類分片中，除wa和id外，其余分片CPU都處于作業態，

二資源&瓶頸分析

從上文我們了解到，Load Average和CPU使用率可被細分為不同的子域指標，指向不同的資源瓶頸，總體來說，指標與資源瓶頸的對應關系基本如下圖所示，

Load高 & CPU高

這是我們最常遇到的一類情況，即load上漲是CPU負載上升導致，根據CPU具體資源分配表現，可分為以下幾類：

CPU sys高

這種情況CPU主要開銷在于系統內核，可進一步查看背景關系切換情況，

如果非自愿背景關系切換較多，說明CPU搶占較為激烈，大量行程由于時間片已到等原因，被系統強制調度，進而發生的背景關系切換，

如果自愿背景關系切換較多，說明可能存在I/O、記憶體等系統資源瓶頸，大量行程無法獲取所需資源，導致的背景關系切換，

CPU si高

這種情況CPU大量消耗在軟中斷，可進一步查看軟中斷型別，一般而言，網路I/O或者執行緒調度引起軟中斷最為常見：

NET_TX & NET_RX，NET_TX是發送網路資料包的軟中斷，NET_RX是接收網路資料包的軟中斷，這兩種型別的軟中斷較高時，系統存在網路I/O瓶頸可能性較大，

SCHED，SCHED為行程調度以及負載均衡引起的中斷，這種中斷出現較多時，系統存在較多行程切換，一般與非自愿背景關系切換高同時出現，可能存在CPU瓶頸，

CPU us高

這種情況說明資源主要消耗在應用行程，可能引發的原因有以下幾類：

死回圈或代碼中存在CPU密集計算，這種情況多核CPU us會同時上漲，

記憶體問題，導致大量FULLGC，阻塞執行緒，這種情況一般只有一核CPU us上漲，

資源等待造成執行緒池滿，連帶引發CPU上漲，這種情況下，執行緒池滿等例外會同時出現，

Load高 & CPU低

這種情況出現的根本原因在于不可中斷睡眠態(TASK_UNINTERRUPTIBLE)行程數較多，即CPU負載不高，但I/O負載較高，可進一步定位是磁盤I/O還是網路I/O導致，

三排查策略

利用現有常用的工具，我們常用的排查策略基本如下圖所示：

從問題發現到最終定位，基本可分為四個階段：

資源瓶頸定位

這一階段通過全域性能檢測工具，初步定位資源消耗例外位點，

常用的工具有：

top、vmstat、tsar(歷史)
- 中斷：/proc/softirqs、/proc/interrupts
- I/O：iostat、dstat

熱點行程定位

定位到資源瓶頸后，可進一步分析具體行程資源消耗情況，找到熱點行程，

常用工具有：

背景關系切換：pidstat -w
CPU：pidstat -u
I/O：iotop、pidstat -d
僵尸行程：ps

執行緒&行程內部資源定位

找到具體行程后，可細化分析行程內部資源開銷情況，

常用工具有：

背景關系切換：pidstat -w -p [pid]
CPU：pidstat -u -p [pid]
I/O: lsof

熱點事件&方法分析

獲取到熱點執行緒后，我們可用trace或者dump工具，將執行緒反向關聯，將問題范圍定位到具體方法&堆疊，

常用的工具有：

perf：Linux自帶性能分析工具，功能類似hotmethod，基于事件采樣原理，以性能事件為基礎，支持針對處理器相關性能指標與作業系統相關性能指標的性能剖析，

jstack
- 結合ps -Lp或者pidstat -p一起使用，可初步定位熱點執行緒，
- 結合zprofile-threaddump一起使用，可統計執行緒分布、等鎖情況，常用與執行緒數增加分析，

strace：跟蹤行程執行時的系統呼叫和所接收的信號，

tcpdump：抓包分析，常用于網路I/O瓶頸定位，

相關閱讀

[1]Linux Load Averages: Solving the Mystery
http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
[2]What exactly is a load average?
http://linuxtechsupport.blogspot.com/2008/10/what-exactly-is-load-average.html

原文鏈接：https://developer.aliyun.com/article/774833?

著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/144904.html

標籤：python

上一篇：一篇文章搞定 Nginx 反向代理與負載均衡

下一篇：流量轉發映射

CPU飆高，系統性能問題如何排查？

一 背景知識