[轉帖]CPU效能原理篇:什麼是負載,應該如何排查

济南小老虎發表於2024-05-21
https://heapdump.cn/monographic/detail/39/4512089

平常的工作中,在衡量伺服器的效能時,經常會涉及到幾個指標,load、cpu、mem、qps、rt等。每個指標都有其獨特的意義,很多時候線上上出現問題時,往往會伴隨著某些指標的異常。大部分情況下,在問題發生之前,某些指標就會提前有異常顯示。

對於這些指標的理解和檢視、異常解決等,是程式設計師們重要的必備技能。本文,主要來介紹一下一個比較重要的指標——機器負載(Load),主要涉及負載的定義、檢視負載方式、負載飆高排查思路等。

什麼是負載

負載(load)是linux機器的一個重要指標,直觀了反應了機器當前的狀態。
來看下負載的定義是怎樣的:

In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute periods.(wikipedia)

簡單解釋一下:在UNIX系統中,系統負載是對當前CPU工作量的度量,被定義為特定時間間隔內執行佇列中的平均執行緒數。load average 表示機器一段時間內的平均load。這個值越低越好。負載過高會導致機器無法處理其他請求及操作,甚至導致當機。

Linux的負載高,主要是由於CPU使用、記憶體使用、IO消耗三部分構成。任意一項使用過多,都將導致伺服器負載的急劇攀升。

檢視機器負載

在Linux機器上,有多個命令都可以檢視機器的負載資訊。其中包括uptime、top、w等。

uptime命令

uptime命令能夠列印系統總共執行了多長時間和系統的平均負載。uptime命令可以顯示的資訊顯示依次為:現在時間、系統已經執行了多長時間、目前有多少登陸使用者、系統在過去的1分鐘、5分鐘和15分鐘內的平均負載。

➜  ~ uptime
13:29  up 23:41, 3 users, load averages: 1.74 1.87 1.97

這行資訊的後半部分,顯示"load average",它的意思是"系統的平均負荷",裡面有三個數字,我們可以從中判斷系統負荷是大還是小。

1.74 1.87 1.97 這三個數字的意思分別是1分鐘、5分鐘、15分鐘內系統的平均負荷。我們一般表示為load1、load5、load15。

w命令

w命令的主要功能其實是顯示目前登入系統的使用者資訊。但是與who不同的是,w命令功能更加強大,w命令還可以顯示:當前時間,系統啟動到現在的時間,登入使用者的數目,系統在最近1分鐘、5分鐘和15分鐘的平均負載。然後是每個使用者的各項資料,專案顯示順序如下:登入帳號、終端名稱、遠 程主機名、登入時間、空閒時間、JCPU、PCPU、當前正在執行程序的命令列。

➜  ~ w
14:08  up 23:41, 3 users, load averages: 1.74 1.87 1.97
USER     TTY      FROM              LOGIN@  IDLE WHAT
hollis   console  -                六14   23:40 -
hollis   s000     -                六14   20:24 -zsh
hollis   s001     -                六15       - w

從上面的w命令的結果可以看到,當前系統時間是14:08,系統啟動到現在經歷了23小時41分鐘,共有3個使用者登入。系統在近1分鐘、5分鐘和15分鐘的平均負載分別是1.74 1.87 1.97。這和uptime得到的結果相同。 下面還列印了一些登入的使用者的各項資料,不詳細介紹了。

top命令

top命令是Linux下常用的效能分析工具,能夠實時顯示系統中各個程序的資源佔用狀況,類似於Windows的工作管理員。

➜  ~ top
Processes: 244 total, 3 running, 9 stuck, 232 sleeping, 1484 threads
14:16:01 Load Avg: 1.74, 1.87, 1.97  CPU usage: 8.0% user, 6.79% sys, 85.19% idle   SharedLibs: 116M resident, 16M data, 14M linkedit. MemRegions: 66523 total, 2152M resident, 50M private, 930M shared.
PhysMem: 7819M used (1692M wired), 370M unused. VM: 682G vsize, 533M framework vsize, 6402060(0) swapins, 7234356(0) swapouts. Networks: packets: 383006/251M in, 334448/60M out.
Disks: 1057821/38G read, 350852/40G written.

PID    COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS          %CPU_ME %CPU_OTHRS UID  FAULTS    COW    MSGSENT   MSGRECV   SYSBSD    SYSMACH   CSW
30845  top          3.0  00:00.49 1/1   0    21    3632K  0B     0B     30845 1394  running  *0[1]           0.00000 0.00000    0    3283+     112    203556+   101770+   8212+     119901+   823+
30842  Google Chrom 0.0  00:47.39 17    0    155   130M   0B     0B     1146  1146  sleeping *0[1]           0.00000 0.00000    501  173746    2697   117678    37821     364228    444830    310043

上面的輸出結果中,Load Avg: 1.74, 1.87, 1.97顯示的就是負載資訊。

機器正常負載範圍

對於機器的Load到底多少算正常的問題,一直都是很有爭議的,不同人有著不同的理解。對於單個CPU,有人認為如果Load超過0.7就算是超出正常範圍了。也有人認為只要不超過1都沒問題。也有人認為,單個CPU的負載在2以下都可以接受。

為什麼會有這麼多不同的理解呢,是因為不同的機器除了CPU影響之外還有其他因素的影響,執行的程式、機器記憶體、甚至是機房溫度等都有可能有區別。

比如,有些機器用於定時執行大量的跑批任務,這個時間段內,Load可能會飆的比較高。而其他時間可能會比較低。那麼這段飆高時間我們要不要去排查問題呢?

我的建議是,最好根據自己機器的實際情況,建立一個指標的基線(如近一個月的平均值),只要日常的load在基線上下範圍內不太大都可以接收,如果差距太多可能就要人為介入檢查了。

但是,總要有個建議的閾值吧,關於這個值。阮一峰在自己的部落格中有過以下建議:

  • 當系統負荷持續大於0.7,你必須開始調查了,問題出在哪裡,防止情況惡化。
  • 當系統負荷持續大於1.0,你必須動手尋找解決辦法,把這個值降下來。
  • 當系統負荷達到5.0,就表明你的系統有很嚴重的問題,長時間沒有響應,或者接近當機了。你不應該讓系統達到這個值。

以上指標都是基於單CPU的,但是現在很多電腦都是多核的。所以,對一般的系統來說,是根據cpu數量去判斷系統是否已經過載(Over Load)的。如果我們認為0.7算是單核機器負載的安全線的話,那麼四核機器的負載最好保持在3(4*0.7 = 2.8)以下。

還有一點需要提一下,在Load Avg的指標中,有三個值,1分鐘系統負荷、5分鐘系統負荷,15分鐘系統負荷。我們在排查問題的時候也是可以參考這三個值的。

一般情況下,1分鐘系統負荷表示最近的暫時現象。15分鐘系統負荷表示是持續現象,並非暫時問題。如果load15較高,而load1較低,可以認為情況有所好轉。反之,情況可能在惡化。

如何降低負載

導致負載高的原因可能很複雜,有可能是硬體問題也可能是軟體問題。
如果是硬體問題,那麼說明機器效能確實就不行了,那麼解決起來很簡單,直接換機器就可以了。

前面我們提過,CPU使用、記憶體使用、IO消耗都可能導致負載高。如果是軟體問題,有可能由於Java中的某些執行緒被長時間佔用、大量記憶體持續佔用等導致。建議從以下幾個方面排查程式碼問題:

1、是否有記憶體洩露導致頻繁GC

2、是否有死鎖發生

3、是否有大欄位的讀寫

4、會不會是資料庫操作導致的,排查SQL語句問題。

這裡還有個建議,如果發現線上機器Load飆高,可以考慮先把堆疊記憶體dump下來後,進行重啟,暫時解決問題,然後再考慮回滾和排查問題。

Java Web應用Load飆高排查思路

#### 1、使用uptime檢視當前load,發現load飆高。

➜ ~ uptime
13:29 up 23:41, 3 users, load averages: 10 10 10


#### 2、使用top命令,檢視佔用CPU較高的程序ID。

➜  ~ top
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1893 admin     20   0 7127m 2.6g  38m S 181.7 32.6  10:20.26 java

發現PID為1893的程序佔用CPU 181%。而且是一個Java程序,基本斷定是軟體問題。

3、使用 top命令,檢視具體是哪個執行緒佔用率較高

➜  ~ top -Hp 1893
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4519 admin     20   0 7127m 2.6g  38m R 18.6 32.6   0:40.11 java

4、使用printf命令檢視這個執行緒的16進位制

➜  ~ printf %x 4519
11a7

5、使用jstack命令檢視當前執行緒正在執行的方法。(Java命令學習系列(二)——Jstack)

➜  ~ jstack 1893 |grep -A 200 11a7
"thread-5" #500 daemon prio=10 os_prio=0 tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
java.lang.Thread.State: RUNNABLE
at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
at sun.misc.URLClassPath.findResource(URLClassPath.java:188)
at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
at com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30)

從上面的執行緒的棧日誌中,可以發現,當前佔用CPU較高的執行緒正在執行我程式碼的com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30) 類。那麼就可以去排查這個類是否用法有問題了。

6、還可以使用jstat(Java命令學習系列(四)——jstat)來檢視GC情況,看看是否有頻繁FGC,然後再使用jmap(Java命令學習系列(三)——Jmap)來dump記憶體,檢視是否存在記憶體洩露

相關文章