SpringBoot假死诊断实战记录
这两天遇到⼀个服务假死的问题,具体现象就是服务不再接收任何请求,客户端会抛出Broken Pipe。
检查系统状态
执⾏top,发现CPU和内存占⽤都不⾼,但是通过命令
springboot其实就是springnetstat -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 进程误认为服务正常,没有触发告警。如果你也遇到类似的情况欢迎⼀起讨论。
好了,以上就是这篇⽂章的全部内容了,希望本⽂的内容对⼤家的学习或者⼯作具有⼀定的参考学习价值,谢谢⼤家对的⽀持。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论