CPU & Load又極速飆升,系統性能問題如何排查?

語言: CN / TW / HK

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

一、背景知識

1、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), 死亡態。程序的真正結束態,這種狀態一般在正常系統中捕獲不到。

2、Load Average & CPU使用率

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

1)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負載)。

2)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使用率可被細分為不同的子域指標,指向不同的資源瓶頸。總體來說,指標與資源瓶頸的對應關係基本如下圖所示。

1、Load高 & CPU高

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

1)CPU sys高

這種情況CPU主要開銷在於系統核心,可進一步檢視上下文切換情況。

  • 如果非自願上下文切換較多,說明CPU搶佔較為激烈,大量程序由於時間片已到等原因,被系統強制排程,進而發生的上下文切換。

  • 如果自願上下文切換較多,說明可能存在I/O、記憶體等系統資源瓶頸,大量程序無法獲取所需資源,導致的上下文切換。

2)CPU si高

這種情況CPU大量消耗在軟中斷,可進一步檢視軟中斷型別。一般而言,網路I/O或者執行緒排程引起軟中斷最為常見:

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

  • SCHED。SCHED為程序排程以及負載均衡引起的中斷,這種中斷出現較多時,系統存在較多程序切換,一般與非自願上下文切換高同時出現,可能存在CPU瓶頸。

3)CPU us高

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

  • 死迴圈或程式碼中存在CPU密集計算。這種情況多核CPU us會同時上漲。

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

  • 資源等待造成執行緒池滿,連帶引發CPU上漲。這種情況下,執行緒池滿等異常會同時出現。

4)Load高 & CPU低

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

三、排查策略

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

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

1、資源瓶頸定位

這一階段通過全域性效能檢測工具,初步定位資源消耗異常位點。

常用的工具有:

  • top、vmstat、tsar(歷史)

  • 中斷:/proc/softirqs、/proc/interrupts

  • I/O:iostat、dstat

2、熱點程序定位

定位到資源瓶頸後,可進一步分析具體程序資源消耗情況,找到熱點程序。

常用工具有:

  • 上下文切換:pidstat -w

  • CPU:pidstat -u

  • I/O:iotop、pidstat -d

找到具體程序後,可細化分析程序內部資源開銷情況。

常用工具有: