1. 周二新需求提测之后,运行到晚上,收到告警短信,生产环境CPU负载过高,先解决问题再排查,运维扩容,有问题机器下线重启上线,CPU使用率正常,服务正常响应。
2. 开始排查问题,把预留的一台有问题的机器用于排查问题,
第一步,top 命令查看cpu资源使用情况,jps -lm找到对应java进程号9021之后,top -H -p9021 看到线程占用情况,cpu利用率93%
记录使用率高的具体的线程id: 9023,9024,9027,9029 在linux中,线程就是轻量级进程
第二步,通过jstack 查看线程堆栈信息,jstack 9021 > jstack_9021.txt , 然后把十进制的9023,9024,9027,9029转成十六进制(0x233f,0x2340, 0x2343, 0x2345)
最后,通过 cat jstack_9021.txt | grep -C 20 0x233f 命令找到了具体的线程信息, 发现把cpu打满的是GC 线程,然后jmap 先总体看内存使用状况,Xmx配置挺高,不存在内存不够,
第三步,通过 jstat -gcutil 9021 3000 20 查看GC回收情况,每间隔3000ms打印一次,打印20次,发现Eden区和Old区都耗尽了,FullGc非常慢,耗时很长,基本可以确定发生了内存泄漏。
jmap -histo 9021 打印内存占用情况,发现主要是新引入第三方RSA包里SignContent对象很大,因为这个对象包含了图片的Base64 decode字节和PDF文件的Base64编码字节。放在集合里,请求结束没有释放导致的。
原文地址:https://www.cnblogs.com/zeenzhou/p/13862945.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。