本篇內(nèi)容介紹了“如何用jvm程序執(zhí)行慢診斷手冊”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!

成都做網(wǎng)站、成都網(wǎng)站設(shè)計服務(wù)團(tuán)隊是一支充滿著熱情的團(tuán)隊,執(zhí)著、敏銳、追求更好,是創(chuàng)新互聯(lián)的標(biāo)準(zhǔn)與要求,同時竭誠為客戶提供服務(wù)是我們的理念。創(chuàng)新互聯(lián)把每個網(wǎng)站當(dāng)做一個產(chǎn)品來開發(fā),精雕細(xì)琢,追求一名工匠心中的細(xì)致,我們更用心!
生產(chǎn)環(huán)境最多的幾種事故之一就是程序執(zhí)行慢,如果是web服務(wù)的話,表現(xiàn)就是響應(yīng)時間長。本文分享,從業(yè)多年形成的排查守則。
首先是系統(tǒng)資源查看,而且必須是在第一步。因?yàn)楹芏嗍鹿识际亲铋_始慢后面就會出現(xiàn)卡死,被系統(tǒng)殺死,程序拋出異常結(jié)束等等情況,當(dāng)時的狀態(tài)沒法保存下來,不行進(jìn)行復(fù)盤,所以第一步先查看系統(tǒng)的資源,如果出現(xiàn)緊張情況,趕緊把狀態(tài)保存。
查看基本就是top命令,可以看到系統(tǒng)cpu,內(nèi)存等資源情況。經(jīng)過查看系統(tǒng)資源大概可以分為以下情況。
如果發(fā)現(xiàn)cpu成為了瓶頸的話,必須馬上進(jìn)行線程情況和當(dāng)時cpu占用情況的保存。在糟糕的情況下,cpu可能被占滿,那時候ssh都登錄不上去了,就沒法獲取當(dāng)時的情況。
使用top -Hp pid獲取線程cpu使用率高的tid
printf "%x\n" tid,獲取線程id的16進(jìn)制主要是為了在jstack中查看
jstack pid|grep tid(16)
然后就會把線程cpu使用率特別高的線程棧打出來,然后可以分析這段邏輯了。
jmap -dump:format=b,file=heapdump.bin pid
這里必須打dump的原因是res過高,可能出發(fā)系統(tǒng)的oom killer,進(jìn)程可能被系統(tǒng)殺死,此時不獲取,可能進(jìn)程就會被殺死了。如果不是系統(tǒng)資源問題,堆dump以后也是要用的。
jstat -gc -h 10 pid 1000
jstat -gcutil -h 10 pid 1000
jstat -gccause -h 10 pid 1000
這里一般是開三個窗口對比看數(shù)據(jù)的。-gc主要是關(guān)注堆的分區(qū)總大小。-gcutil主要是關(guān)注已使用的百分比。-gccause主要是關(guān)注fgc次數(shù),時間以及gc原因。
內(nèi)存問題的分類就比較多了,造成問題的卡頓的根本其實(shí)是gc問題。stw的時候虛擬機(jī)停頓了,導(dǎo)致反應(yīng)不過來了。
這種情況就利用mat去查看dump分析吧,可能出現(xiàn)內(nèi)存使用不合理或者內(nèi)存泄漏,這里需要根據(jù)代碼來分析。
jps -lvm
查看一下jvm參數(shù)設(shè)置,很可能是參數(shù)設(shè)置不合理,-XX:MetaspaceSize是發(fā)生gc的最小空間,這里是不是設(shè)置太小。MaxMetaspaceSize,MaxPermSize的值是否設(shè)置太小。java6如果設(shè)置都不小而且還占滿了,那就得檢測代碼里是不是在運(yùn)行時常量池加了字符串。1.7,1.8就考慮是不是業(yè)務(wù)用了什么字節(jié)碼生成技術(shù),動態(tài)做了一些字節(jié)碼操作。
gccause查看gc的原因是system.gc()。需要檢測是否用了rmi,使用了直接內(nèi)存,或者業(yè)務(wù)代碼調(diào)用了system.gc()。直接內(nèi)存查看現(xiàn)在沒有現(xiàn)成的工具。可以使用我在github上放著的小工具查看。地址如下https://github.com/xpbob/jstatassist
空間都不是特別緊張,但是gc次數(shù)頻繁,并且不是system.gc()。那可能就是gc參數(shù)設(shè)置不對了,例如cms,老年代回收是一個2秒一次的輪訓(xùn)操作,很有可能是現(xiàn)在的空間占用每次都是滿足gc的條件的,于是出現(xiàn)了這種情況。
gc時間特別長,這個就從gc算法選擇還有內(nèi)存情況來協(xié)調(diào)參數(shù)吧。但是有兩個特例,cms和g1。這兩個垃圾回收器都是有單線程回收的算法的可能的,這里需要gc日志分析確認(rèn)。
這種情況可能性太大,常見的是jni,jna操作,mmap文件,直接內(nèi)存使用,jdk的bug。需要根據(jù)實(shí)際情況來分析。
如果以上表現(xiàn)都沒有的話,那需要不斷的打jstack去看線程棧的變化。這個只能是結(jié)合業(yè)務(wù)來看。
“如何用jvm程序執(zhí)行慢診斷手冊”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
網(wǎng)站欄目:如何用jvm程序執(zhí)行慢診斷手冊
URL標(biāo)題:http://www.chinadenli.net/article8/gidiop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供小程序開發(fā)、品牌網(wǎng)站建設(shè)、App設(shè)計、網(wǎng)站維護(hù)、網(wǎng)站導(dǎo)航、建站公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)