轉載自本人博客
原文地址:https://www.deanwangpro.com/2...
這兩天遇到一個服務假死的問題,具體現象就是服務不再接收任何請求,客戶端會拋出Broken Pipe。
檢查系統狀態
執行top,發現CPU和內存佔用都不高,但是通過命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
發現有大量的CLOSE_WAIT端口占用,繼續調用該服務的api,等待超時之後發現CLOSE_WAIT的數量也沒有上升,也就是說服務幾乎完全僵死。
檢查JVM情況
懷疑可能是線程有死鎖,決定先dump一下線程情況,執行
jstack <pid> > /tmp/thread.hump
發現tomcat線程基本也正常,都是parking狀態。
這就比較奇怪了,繼續想是不是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。一定是有什麼原因觸發了FGC,好在我們打開了GC log。
發現一段時間內頻繁發生Allocation Failure引起的Full GC。而且eden區的使用佔比也很大,考慮有頻繁新建對象逃逸到老年代造成問題。詢問了一下業務的開發,確認有一個外部對接API沒有分頁,查詢後可能會產生大量對象。
由於外部API暫時無法聯繫對方修改,所以爲了先解決問題,對原有的MaxNewSize進擴容,從192MB擴容到一倍。經過幾天的觀察,發現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進程誤認爲服務正常,沒有觸發告警。如果你也遇到類似的情況歡迎一起討論。