Spring Boot假死診斷的實例分析,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
創(chuàng)新互聯建站專注為客戶提供全方位的互聯網綜合服務,包含不限于成都做網站、網站制作、成都外貿網站建設、上街網絡推廣、小程序設計、上街網絡營銷、上街企業(yè)策劃、上街品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等,從售前售中售后,我們都將竭誠為您服務,您的肯定,是我們最大的嘉獎;創(chuàng)新互聯建站為所有大學生創(chuàng)業(yè)者提供上街建站搭建服務,24小時服務熱線:028-86922220,官方網址:aaarwkj.com
這兩天遇到一個服務假死的問題,具體現象就是服務不再接收任何請求,客戶端會拋出Broken Pipe。
執(zhí)行top,發(fā)現CPU和內存占用都不高,但是通過命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
發(fā)現有大量的CLOSE_WAIT端口占用,繼續(xù)調用該服務的api,等待超時之后發(fā)現CLOSE_WAIT的數量也沒有上升,也就是說服務幾乎完全僵死。
懷疑可能是線程有死鎖,決定先dump一下線程情況,執(zhí)行
jstack <pid> > /tmp/thread.hump
發(fā)現tomcat線程基本也正常,都是parking狀態(tài)。
這就比較奇怪了,繼續(xù)想是不是GC導致了STW,使用jstat
查看垃圾回收情況
app@server:/tmp$ jstat -gcutil 1 2000 10 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 27.79 65.01 15.30 94.75 92.23 1338 44.375 1881 475.064 519.439
一看嚇一跳,FGC的次數居然超過了YGC,時長有475s。一定是有什么原因觸發(fā)了FGC,好在我們打開了GC log。
發(fā)現一段時間內頻繁發(fā)生Allocation Failure引起的Full GC。而且eden區(qū)的使用占比也很大,考慮有頻繁新建對象逃逸到老年代造成問題。詢問了一下業(yè)務的開發(fā),確認有一個外部對接API沒有分頁,查詢后可能會產生大量對象。
由于外部API暫時無法聯系對方修改,所以為了先解決問題,對原有的MaxNewSize進擴容,從192MB擴容到一倍。經過幾天的觀察,發(fā)現gc基本趨于正常
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 3.37 60.55 8.60 95.08 92.98 87 2.421 0 0.000 2.421
擴容之前對heap進行了dump
jmap -dump:format=b,file=heapDump <PID>
通過MAT分析內存泄露,居然疑似是jdbc中的一個類,但其實整體占用堆容量并不多。
分析了線程數量,大約是240多條,與正常時也并沒有很大的出入。而且大量的是在sleep的定時線程。
本次排查其實并未找到真正的原因,間接表象是FGC頻繁導致服務假死。而且acturator端口是正常工作的,導致health check進程誤認為服務正常,沒有觸發(fā)告警。如果你也遇到類似的情況歡迎一起討論。
關于Spring Boot假死診斷的實例分析問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注創(chuàng)新互聯行業(yè)資訊頻道了解更多相關知識。
網頁標題:SpringBoot假死診斷的實例分析
本文網址:http://aaarwkj.com/article22/gooscc.html
成都網站建設公司_創(chuàng)新互聯,為您提供搜索引擎優(yōu)化、網站導航、網站設計公司、服務器托管、電子商務、微信公眾號
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯