當(dāng)前位置：首頁 > 编程语言 > java >内容正文

java

dump分析工具_Java应用CPU过高，如何排查？参考解决思路和常用工具总结

發(fā)布時(shí)間：2023/12/20 java 47 豆豆

生活随笔收集整理的這篇文章主要介紹了 dump分析工具_Java应用CPU过高，如何排查？参考解决思路和常用工具总结小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

本文總結(jié)了一些常見的線上應(yīng)急現(xiàn)象和對(duì)應(yīng)排查步驟和工具。分享的主要目的是想讓對(duì)線上問題接觸少的同學(xué)有個(gè)預(yù)先認(rèn)知，免得在遇到實(shí)際問題時(shí)手忙腳亂。畢竟作者自己也是從手忙腳亂時(shí)走過來的。

只不過這里先提示一下。在線上應(yīng)急過程中要記住，只有一個(gè)總體目標(biāo)：盡快恢復(fù)服務(wù)，消除影響。不管處于應(yīng)急的哪個(gè)階段，我們首先必須想到的是恢復(fù)問題，恢復(fù)問題不一定能夠定位問題，也不一定有完美的解決方案，也許是通過經(jīng)驗(yàn)判斷，也許是預(yù)設(shè)開關(guān)等，但都可能讓我們達(dá)到快速恢復(fù)的目的，然后保留部分現(xiàn)場(chǎng)，再去定位問題、解決問題和復(fù)盤。

在大多數(shù)情況下，我們都是先優(yōu)先恢復(fù)服務(wù)，保留下當(dāng)時(shí)的異常信息(內(nèi)存dump、線程dump、gc log等等，在緊急情況下甚至可以不用保留，等到事后去復(fù)現(xiàn))，等到服務(wù)正常，再去復(fù)盤問題。

常見現(xiàn)象：CPU 利用率高/飆升

場(chǎng)景預(yù)設(shè)：

監(jiān)控系統(tǒng)突然告警，提示服務(wù)器負(fù)載異常。

預(yù)先說明：

CPU飆升只是一種現(xiàn)象，其中具體的問題可能有很多種，這里只是借這個(gè)現(xiàn)象切入。

注：CPU使用率是衡量系統(tǒng)繁忙程度的重要指標(biāo)。但是CPU使用率的安全閾值是相對(duì)的，取決于你的系統(tǒng)的IO密集型還是計(jì)算密集型。一般計(jì)算密集型應(yīng)用CPU使用率偏高load偏低，IO密集型相反。

常見原因：

頻繁 gc
死循環(huán)、線程阻塞、io wait...etc

模擬

這里為了演示，用一個(gè)最簡(jiǎn)單的死循環(huán)來模擬CPU飆升的場(chǎng)景，下面是模擬代碼，

在一個(gè)最簡(jiǎn)單的SpringBoot Web 項(xiàng)目中增加CpuReaper這個(gè)類，

@Componentpublic?class?CpuReaper?{????@PostConstruct????public?void?cpuReaper()?{????????int?num?=?0;????????long?start?=?System.currentTimeMillis()?/?1000;????????while?(true)?{????????????num?=?num?+?1;????????????if?(num?==?Integer.MAX_VALUE)?{????????????????System.out.println("reset");????????????????num?=?0;????????????}????????????if?((System.currentTimeMillis()?/?1000)?-?start?>?1000)?{????????????????return;????????????}????????}????}}

打包成jar之后，在服務(wù)器上運(yùn)行。java -jar cpu-reaper.jar

(1)第一步：定位出問題的線程

方法 a: 傳統(tǒng)的方法

1、top 定位CPU 最高的進(jìn)程執(zhí)行top命令，查看所有進(jìn)程占系統(tǒng)CPU的排序，定位是哪個(gè)進(jìn)程搞的鬼。在本例中就是咱們的java進(jìn)程。PID那一列就是進(jìn)程號(hào)。

2、top -Hp pid 定位使用 CPU 最高的線程

3、printf '0x%x' tid 線程 id 轉(zhuǎn)化 16 進(jìn)制

>?printf?'0x%x'?12817>?0x3211

4、jstack pid | grep tid 找到線程堆棧

>?jstack?12816?|?grep?0x3211?-A?30

方法 b: show-busy-java-threads

這個(gè)腳本來自于github上一個(gè)開源項(xiàng)目，項(xiàng)目提供了很多有用的腳本，show-busy-java-threads就是其中的一個(gè)。使用這個(gè)腳本，可以直接簡(jiǎn)化方法A中的繁瑣步驟。如下，

>?wget?--no-check-certificate?https://raw.github.com/oldratlee/useful-scripts/release-2.x/bin/show-busy-java-threads>?chmod?+x?show-busy-java-threads>?./show-busy-java-threadsshow-busy-java-threads#?從所有運(yùn)行的Java進(jìn)程中找出最消耗CPU的線程(缺省5個(gè))，打印出其線程棧#?缺省會(huì)自動(dòng)從所有的Java進(jìn)程中找出最消耗CPU的線程，這樣用更方便#?當(dāng)然你可以手動(dòng)指定要分析的Java進(jìn)程Id，以保證只會(huì)顯示你關(guān)心的那個(gè)Java進(jìn)程的信息show-busy-java-threads?-p?show-busy-java-threads?-c?

方法 c: arthas thread

阿里開源的arthas現(xiàn)在已經(jīng)幾乎包攬了我們線上排查問題的工作，提供了一個(gè)很完整的工具集。在這個(gè)場(chǎng)景中，也只需要一個(gè)thread -n命令即可。

>?curl?-O?https://arthas.gitee.io/arthas-boot.jar?#?下載

后續(xù)

通過第一步，找出有問題的代碼之后，觀察到線程棧之后。我們就要根據(jù)具體問題來具體分析。這里舉幾個(gè)例子。

1、情況一：發(fā)現(xiàn)使用CPU最高的都是GC 線程。

GC?task?thread#0?(ParallelGC)"?os_prio=0?tid=0x00007fd99001f800?nid=0x779?runnableGC?task?thread#1?(ParallelGC)"?os_prio=0?tid=0x00007fd990021800?nid=0x77a?runnable?GC?task?thread#2?(ParallelGC)"?os_prio=0?tid=0x00007fd990023000?nid=0x77b?runnable?GC?task?thread#3?(ParallelGC)"?os_prio=0?tid=0x00007fd990025000?nid=0x77c?runnabl

2、情況二：發(fā)現(xiàn)使用CPU最高的是業(yè)務(wù)線程

io wait
- 比如此例中，就是因?yàn)榇疟P空間不夠?qū)е碌膇o阻塞
等待內(nèi)核態(tài)鎖，如 synchronized
- jstack -l pid | grep BLOCKED 查看阻塞態(tài)線程堆棧
- dump 線程棧，分析線程持鎖情況。
- arthas提供了thread -b，可以找出當(dāng)前阻塞其他線程的線程。針對(duì) synchronized 情況

常見現(xiàn)象：頻繁 GC

1、回顧GC流程

在了解下面內(nèi)容之前，請(qǐng)先花點(diǎn)時(shí)間回顧一下GC的整個(gè)流程。

接前面的內(nèi)容，這個(gè)情況下，我們自然而然想到去查看gc 的具體情況。

方法a : 查看gc 日志
方法b : jstat -gcutil 進(jìn)程號(hào) 統(tǒng)計(jì)間隔毫秒統(tǒng)計(jì)次數(shù)(缺省代表一致統(tǒng)計(jì)
方法c : 如果所在公司有對(duì)應(yīng)用進(jìn)行監(jiān)控的組件當(dāng)然更方便(比如Prometheus + Grafana)

這里對(duì)開啟 gc log 進(jìn)行補(bǔ)充說明。一個(gè)常常被討論的問題(慣性思維)是在生產(chǎn)環(huán)境中GC日志是否應(yīng)該開啟。因?yàn)樗a(chǎn)生的開銷通常都非常有限，因此我的答案是需要開啟。但并不一定在啟動(dòng)JVM時(shí)就必須指定GC日志參數(shù)。

HotSpot JVM有一類特別的參數(shù)叫做可管理的參數(shù)。對(duì)于這些參數(shù)，可以在運(yùn)行時(shí)修改他們的值。我們這里所討論的所有參數(shù)以及以“PrintGC”開頭的參數(shù)都是可管理的參數(shù)。這樣在任何時(shí)候我們都可以開啟或是關(guān)閉GC日志。比如我們可以使用JDK自帶的jinfo工具來設(shè)置這些參數(shù)，或者是通過JMX客戶端調(diào)用HotSpotDiagnostic MXBean的setVMOption方法來設(shè)置這些參數(shù)。

這里再次大贊arthas??，它提供的vmoption命令可以直接查看，更新VM診斷相關(guān)的參數(shù)。

獲取到gc日志之后，可以上傳到GC easy幫助分析，得到可視化的圖表分析結(jié)果。

2、GC 原因及定位

prommotion failed

從S區(qū)晉升的對(duì)象在老年代也放不下導(dǎo)致 FullGC(fgc 回收無效則拋 OOM)。

可能原因：

survivor 區(qū)太小，對(duì)象過早進(jìn)入老年代查看 SurvivorRatio 參數(shù)
大對(duì)象分配，沒有足夠的內(nèi)存dump 堆，profiler/MAT 分析對(duì)象占用情況
old 區(qū)存在大量對(duì)象dump 堆，profiler/MAT 分析對(duì)象占用情況

你也可以從full GC 的效果來推斷問題，正常情況下，一次full GC應(yīng)該會(huì)回收大量?jī)?nèi)存，所以 正常的堆內(nèi)存曲線應(yīng)該是呈鋸齒形。如果你發(fā)現(xiàn)full gc 之后堆內(nèi)存幾乎沒有下降，那么可以推斷：**堆中有大量不能回收的對(duì)象且在不停膨脹，使堆的使用占比超過full GC的觸發(fā)閾值，但又回收不掉，導(dǎo)致full GC一直執(zhí)行。換句話來說，可能是內(nèi)存泄露了。

一般來說，GC相關(guān)的異常推斷都需要涉及到內(nèi)存分析，使用jmap之類的工具dump出內(nèi)存快照(或者 Arthas的heapdump)命令，然后使用MAT、JProfiler、JVisualVM等可視化內(nèi)存分析工具。

至于內(nèi)存分析之后的步驟，就需要小伙伴們根據(jù)具體問題具體分析啦。

六、涉及工具

再說下一些工具。

Arthas
useful-scripts
GC easy
Smart Java thread dump analyzer - thread dump analysis in seconds
PerfMa - Java虛擬機(jī)參數(shù)/線程dump/內(nèi)存dump分析
Linux 命令
Java N 板斧
MAT、JProfiler...等可視化內(nèi)存分析工具

總結(jié)

以上是生活随笔為你收集整理的dump分析工具_Java应用CPU过高，如何排查？参考解决思路和常用工具总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。