时间:2021-05-20
这两天遇到一个服务假死的问题,具体现象就是服务不再接收任何请求,客户端会抛出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 10S0 S1 E O M CCS YGC YGCT FGC FGCT GCT0.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 GCT0.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进程误认为服务正常,没有触发告警。如果你也遇到类似的情况欢迎一起讨论。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
一)spring-boot-starter命名规则自动配置模块命名规则:xxx-spring-boot,如:aspectlog-spring-boot启动器命名
1.什么是spring-boot-devtoolsspring-boot-devtools是spring-boot项目开发时的一个热部署工具,安装了spring
1.加入mybatis-spring-boot-stater的Maven依赖org.mybatis.spring.bootmybatis-spring-boot
一、使用mybatis-spring-boot-starter1、添加依赖org.mybatis.spring.bootmybatis-spring-boot-
女朋友他们项目用了spring-boot,以spring-boot-parent作为parent:org.springframework.bootspring-