Java應用/JVM宕機排查步驟操作
相信大家都遇到過,自己的Java應用執行一段時間就宕機了或者響應請求特別慢。這時候就需要我們了來找出問題所在了。絕大部分都是程式碼問題導致的。
一、服務宕機
如果是服務宕機,發生致命問題導致程序已經死掉了,那麼已經訪問不了了,通常都是CPU問題引起的,程式一般會自己生成javacore檔案,一般生成位置在/root目錄或jar包同目錄下。JavaCore檔案主要儲存的是Java應用各執行緒在某一時刻的執行的位置,即JVM執行到哪一個類、哪一個方法、哪一個行上。
找到這個檔案,執行命令
gdb java <檔案>
bt
如果檔案沒有損壞的話可以看到完整的棧呼叫資訊。就可以定位到問題程式碼所在。
我曾經就因為底層呼叫的一個geo庫出問題,導致程式直接掛掉,分析core檔案可以清晰的看到native方法的呼叫。
二、服務響應請求慢
出現這個問題一般都是記憶體溢位,GC執行緒一直在重複GC,沒有執行緒來處理使用者請求,或者問題程式碼導致CPU佔用過高。
程式崩潰前會生成HeapDump檔案,也可以手動生成,HeapDump是一個二進位制檔案,它儲存了某一時刻JVM堆中物件使用情況。
在JVM啟動引數要配置好HeapDump的生成位置和配置列印gc日誌。這樣才能排查問題。
先分析GC日誌
線上分析工具地址:https://gceasy.io/
把gc檔案上傳就好了,就可以看到分析結果。重點關注什麼區域的GC佔用最多時間。
離線分析工具:GCViewer 是一款開源的GC日誌分析工具。
如果程式記憶體溢位,通過分析gc檔案可以發現程式記憶體佔用機會100%而且一直重複GC。
分析HeapDump檔案
1、先找到Java應用的pid
ps -ef | grep java 或者 jps -l 檢視
2、檢視堆記憶體使用量
jmap -heap <pid>
3、檢視Java程序中的每一個執行緒的情況(linux),可以清晰的看到每一個執行緒的cpu及記憶體使用情況
top -Hp <pid>
window下可以藉助工具 Process Explorer,
4、列印執行緒快照資訊,儲存到檔案xxx.txt中方便檢視
jstack <pid> > xxx.txt
參考這一篇文章: https://www.jb51.net/article/195797.htm
5、通過top -Hp <pid>看到的執行緒id是10進位制的,我們輸出到xxx.txt中的是16進位制,所以需要轉一下,找一個異常執行緒tid
printf "%x" <tid> 假如輸出為 1111
6、在xxx.txt檔案中查詢tid為1111的棧資訊,可以看到這個執行緒在幹什麼,定位到問題程式碼。
7、程式宕機會自動產生dump檔案,若沒有宕機就手動匯出dump檔案
jmap -dump:format=b,file=檔名 <pid>
桌面分析工具:Eclipse Memory Analyzer,它有windows版的和Linux版的
windows下:把HeapDump檔案放進去就可以了,分析完後,很直觀的看到當前記憶體佔用量最高的是某個類的某個引數。持有了多少個物件,這些物件佔用了多少記憶體,從而定位到問題程式碼。
Linux下:先把Eclipse Memory Analyzer版上傳到伺服器,解壓,假如/home/mat為解壓後路徑,執行命令
/home/mat/ParseHeapDump.sh <檔名> org.eclipse.mat.api:suspects prg.eclipse.mat.api:overview
org.eclipse.mat.api:top_components
分析完之後會在當前檔案生成結果檔案。下載到本地檢視即可。
以上這篇Java應用/JVM宕機排查步驟操作就是小編分享給大家的全部內容了,希望能給大家一個參考,也希望大家多多支援我們。