人妖在线一区,国产日韩欧美一区二区综合在线,国产啪精品视频网站免费,欧美内射深插日本少妇

新聞動態(tài)

Tomcat進(jìn)程占用CPU過高的解決方法

發(fā)布日期:2021-12-14 06:07 | 文章來源:源碼之家

CPU經(jīng)常會成為系統(tǒng)性能的瓶頸,可能:

  • 內(nèi)存泄露導(dǎo)致頻繁GC,進(jìn)而引起CPU使用率過高
  • 代碼Bug創(chuàng)建了大量的線程,導(dǎo)致CPU頻繁上下文切換

通常所說的CPU使用率過高,隱含著一個用來比較高與低的基準(zhǔn)值,比如

  • JVM在峰值負(fù)載下的平均CPU利用率40%
  • CPU使用率飆到80%就可認(rèn)為不正常

JVM進(jìn)程包含多個Java線程:

  • 一些在等待工作
  • 另一些則正在執(zhí)行任務(wù)

最重要的是找到哪些線程在消耗CPU,通過線程棧定位到問題代碼
如果沒有找到個別線程的CPU使用率特別高,考慮是否線程上下文切換導(dǎo)致了CPU使用率過高。

案例

程序模擬CPU使用率過高 - 在線程池中創(chuàng)建4096個線程

在Linux環(huán)境下啟動程序:

java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar

線程棧大小指定為256KB。對于測試程序來說,操作系統(tǒng)默認(rèn)值8192KB過大,因為需要創(chuàng)建4096個線程。

使用top命令,我們看到Java進(jìn)程的CPU使用率達(dá)到了961.6%,注意到進(jìn)程ID是55790。

用更精細(xì)化的top命令查看這個Java進(jìn)程中各線程使用CPU的情況:

#top -H -p 55790

可見,有個叫“scheduling-1”的線程占用了較多的CPU,達(dá)到了42.5%。因此下一步我們要找出這個線程在做什么事情。

為了找出線程在做什么,用jstack生成線程快照。
jstack輸出較大,一般將其寫入文件:

jstack 55790 > 55790.log

打開55790.log,定位到第4步中找到的名為 scheduling-1 的線程,其線程棧:

看到AbstractExecutorService#submit這個函數(shù)調(diào)用,說明它是Spring Boot啟動的周期性任務(wù)線程,向線程池中提交任務(wù),該線程消耗了大量CPU。

上下文切換開銷?

經(jīng)歷上述過程,往往已經(jīng)可以定位到大量消耗CPU的線程及bug代碼,比如死循環(huán)。但對于該案例:Java進(jìn)程占用的CPU是961.6%, 而“scheduling-1”線程只占用了42.5%的CPU,那其它CPU被誰占用了?

第4步用top -H -p pid命令看到的線程列表中還有許多名為“pool-1-thread-x”的線程,它們單個的CPU使用率不高,但是似乎數(shù)量比較多。你可能已經(jīng)猜到,這些就是線程池中干活的線程。那剩下的CPU是不是被這些線程消耗了呢?

還需要看jstack的輸出結(jié)果,主要是看這些線程池中的線程是不是真的在干活,還是在“休息”呢?

發(fā)現(xiàn)這些“pool-1-thread-x”線程基本都處WAITING狀態(tài)。

  • Blocking指的是一個線程因為等待臨界區(qū)的鎖(Lock或者synchronized關(guān)鍵字)而被阻塞的狀態(tài),請你注意的是處于這個狀態(tài)的線程還沒有拿到鎖
  • Waiting指的是一個線程拿到了鎖,但需等待其他線程執(zhí)行某些操作。比如調(diào)用了Object.wait、Thread.join或LockSupport.park方法時,進(jìn)入Waiting狀態(tài)。前提是這個線程已經(jīng)拿到鎖了,并且在進(jìn)入Waiting狀態(tài)前,os層面會自動釋放鎖,當(dāng)?shù)却龡l件滿足,外部調(diào)用了Object.notify或者LockSupport.unpark方法,線程會重新競爭鎖,成功獲得鎖后才能進(jìn)入到Runnable狀態(tài)繼續(xù)執(zhí)行。

回到我們的“pool-1-thread-x”線程,這些線程都處在“Waiting”狀態(tài),從線程棧我們看到,這些線程“等待”在getTask方法調(diào)用上,線程嘗試從線程池的隊列中取任務(wù),但是隊列為空,所以通過LockSupport.park調(diào)用進(jìn)到了“Waiting”狀態(tài)。那“pool-1-thread-x”線程有多少個呢?通過下面這個命令來統(tǒng)計一下,結(jié)果是4096,正好跟線程池中的線程數(shù)相等。

grep -o 'pool-2-thread' 55790.log | wc -l

剩下CPU到底被誰消耗了?
應(yīng)該懷疑CPU的上下文切換開銷了,因為我們看到Java進(jìn)程中的線程數(shù)比較多。

下面通過vmstat命令來查看一下操作系統(tǒng)層面的線程上下文切換活動:

cs那一欄表示線程上下文切換次數(shù),in表示CPU中斷次數(shù),我們發(fā)現(xiàn)這兩個數(shù)字非常高,基本證實了我們的猜測,線程上下文切切換消耗了大量CPU。
那具體是哪個進(jìn)程導(dǎo)致的呢?

停止Spring Boot程序,再次運行vmstat命令,會看到in和cs都大幅下降,這就證實引起線程上下文切換開銷的Java進(jìn)程正是55790。

總結(jié)

遇到CPU過高,首先定位哪個進(jìn)程導(dǎo)致的,之后可以通過top -H -p pid命令定位到具體的線程。
其次還要通jstack查看線程的狀態(tài),看看線程的個數(shù)或者線程的狀態(tài),如果線程數(shù)過多,可以懷疑是線程上下文切換的開銷,我們可以通過vmstat和pidstat這兩個工具進(jìn)行確認(rèn)。

到此這篇關(guān)于Tomcat進(jìn)程占用CPU過高的解決方法的文章就介紹到這了,更多相關(guān)Tomcat進(jìn)程占用CPU過高內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站!

版權(quán)聲明:本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來,僅供學(xué)習(xí)參考,不代表本站立場,如有內(nèi)容涉嫌侵權(quán),請聯(lián)系alex-e#qq.com處理。

實時開通

自選配置、實時開通

免備案

全球線路精選!

全天候客戶服務(wù)

7x24全年不間斷在線

專屬顧問服務(wù)

1對1客戶咨詢顧問

在線
客服

在線客服:7*24小時在線

客服
熱線

400-630-3752
7*24小時客服服務(wù)熱線

關(guān)注
微信

關(guān)注官方微信
頂部