效能分析之CPU分析-從CPU呼叫高到具體程式碼行(JAVA)

Zee_7D發表於2021-06-16

 

通常情況下,效能報告中只說CPU使用率高的時候,並不能幫助定位問題。因為CPU高會有多種不同的情況。CPU有五種狀態(us sy id wa st), 在vmstat中能顯示出來,這個想必很多人都清楚。在程式碼消耗CPU的時候(這也是通常效能分析中會遇到的),是US狀態的CPU。當然還存在一種情況,就是程式碼產生的系統呼叫特別高,這種情況下SY的CPU也會高(這種情況比較少見,在我的職業生涯中只見過一次)。對於JAVA語言來說,我們不需要特別複雜的profile工具就可以做到定位到程式碼。 

在寫具體的分析方法之前,需要說一下執行緒的狀態轉換關係,我們先來看一下系統級的執行緒狀態轉換關係。

通過這個轉換關係,可以看到,線上程產生之後,會先到ready的狀態。在這個狀態上是在等待CPU的。而在runing狀態才是真正在CPU上執行的。請注意這個區別。

而vmstat顯示的 r 列是包括了ready和running的執行緒(會因作業系統的不同有區別,但是對大部分linux系統都是這樣)。請注意這一點,因為網上有很多在寫vmstat的解釋的時候,說 r 列是表示正在執行的程式數或者說 r 是表示正在執行的執行緒數,這一點是不對的。給大家看一個例子(這也是下面要說到的例子):

這是我的一個雲伺服器上正在執行的top。可以看到當前tasks(程式)中只有一個是running的狀態的。而這時的vmstat呢?

這個伺服器只有兩個CPU,所以如果r是說正在執行的程式或執行緒數的話肯定是不正確的,因為兩個CPU同時執行的最多是兩個執行緒。

所以請記住,這個 r 值就包括了等待CPU的執行緒(也就是ready狀態的)和正在執行的執行緒(也就是running狀態的)。

以後有時間再解釋其他系統級的執行緒狀態,可能有些人覺得其他狀態也沒什麼好解釋的,但是在效能分析中,執行緒的狀態和一些效能計數器是有關聯關係的,比如說suspended狀態是CPU時間片用完導致暫時被換出;而blocked是因為要等待某個條件被滿足而阻塞;並且這兩種狀態都有可能導致CPU使用率高。在分析的過程中,這些資訊給我們的是一個方向。所以前面說到僅說CPU高不能幫助分析問題,因為CPU高有多種原因。

 

因為下面要說的是JAVA,所以來看一下JAVA的執行緒狀態轉換關係。

從這個圖中,我們可以看到JAVA的程式有多種狀態(具體狀態的解釋請自行搜尋),怎麼看到這些狀態都在幹什麼,就需要把棧打出來看。在棧中,可以看到具體對應的程式碼(對其他編譯語言來說,要看看到正在執行的code也是要看棧的)。另外,在效能分析中,棧的分析是非常重要的一塊內容,今天因為只是為了說明從CPU高怎麼定位到程式碼層,所以不過多解釋執行緒的狀態了,以後有時間再寫文章說明。

 

例項:

下面來操作一下,首先執行一個消耗CPU的JAVA例項(例項是7D Group成員所編,有興趣動手操作的可以到網上隨便找一個小例子或自己編寫一個)。檢視vmstat的狀態。

從上圖可以看到左邊視窗在執行一個消耗CPU的Demo,而右邊的視窗看到當前系統的CPU已經完全被消耗掉了。程式號通過top命令就可以知道:

下面就要看一下這個程式中的哪些執行緒消耗了CPU。

通過pidstat可以看到(不好意思的是,pidstat的截圖被我覆蓋掉了,又不想重新開始所以就不截圖啦),有10個執行緒消耗著CPU資源。我把命令放在這裡,有興趣的可以自己操作。

pidstat -p 10846 -u -d -t -w -h 1 1000  

從上命令可以看到,有多個執行緒消耗著CPU。執行緒ID是:10861、10862、10863等等。

用jstack做一下thread dump。 

[root@7dgroup ~]# jstack -l 10846 > 10846.threaddump

再開啟這個生成的檔案。

 

nid是指native ID,對應著系統級的tid。只不過TID顯示的是10程式的,NID顯示的是16進位制的。

我們轉換一個執行緒號來查詢。

[root@7dgroup ~]# printf %x'\n' 10861

2a6d

再對應到threaddump檔案中。

顯然可以去查這個CPUTestThreadDemo.java的第13行了。

 

從這個例子可以看出,對java的程式碼消耗CPU高的分析只需要通過系統級的命令和JDK自帶的命令就可以完成了。因為這個例子非常簡單,步驟比較清楚。但在實際分析程式碼眾多,邏輯複雜的應用,有可能你看到的是CPU線上程上的消耗是在不停的切換的,所以就需要多做些thread dump,一個個分析。當然藉助些工具分析,通常可以讓我們在分析複雜的應用時事半功倍。

這裡只說明一個思路。

 

對JAVA的分析來說,已經有非常多的人寫了非常多的文章了,我之所以寫這個文章,是為了讓文章能更系列一些。

 

  •  
     
     
 

相關文章