springboot应用,cpu高、内存高问题排查

这篇具有很好参考价值的文章主要介绍了springboot应用,cpu高、内存高问题排查。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前几天,排查了2个生产问题。一个cpu高,一个内存高。今天把解决过程整理一下

1、cpu高问题排查

先说cpu高的这个问题
新系统,上线半年,一直比较稳定。有一天,运维过来说:cpu有点高,超过80%了。这个系统的量没有那么大,也没有什么很复杂的计算任务。cpu不应该这么高。

1.1、获取栈日志

让运维拿了2份栈日志,两份栈日志间隔1分钟左右获取。之所以下载两份,是为了比较,如果两份栈日志都有某个功能在执行,那这个功能就有很大的嫌疑。

//栈日志获取方式.将pid换成你系统的pid
jstack -l pid >> order.txt

1.2、分析栈日志

打开栈日志,直接搜项目代码里的包名,只要两份日志都有这个包名,那基本八九不离十,看一下对应的逻辑就行了。
我这个cpu高的原因,是实习小伙伴做了一个excel文件解析的功能,解析完成之后的业务逻辑处理,有几个点非常耗时,加上这段时间,业务调用的比较频繁,cpu就猛增。知道了原因,解决起来就比较简单了。

2、内存高问题排查

再说内存高,在排查cpu问题的时候,运维就说了一句:内存有点高,先给你加点内存。我觉着不太对,就看了看趋势,趋势很陡峭,而且不下降,这肯定是有问题的,接下来就是漫长的排查过程,整个排查过程大概持续了3天左右。

2.1、dump日志分析

让运维拿了dump日志。

//dump日志获取命令 pid替换为你的系统pid
jmap -dump:format=b,file=/tmp/order.dump pid

本地装了MAT,分析了一下内存的占用。将近3个G的文件,2.7G都是不可达的对象
springboot3.2.1 gateway cpu 异常,springboot,性能优化
这说明,内存虽然涨的快,但是可以回收。

2.2、堆内存使用情况

再看一下堆内存的情况(生产机器用的是CMS垃圾收集器)

//查看堆内存的使用情况
jsat -gcutil pid 间隔 次数
//举例
输出pid为200的程序的堆内存使用情况,每隔1秒打印一次,不限制次数
jsat -gcutil 200 1000

springboot3.2.1 gateway cpu 异常,springboot,性能优化
我这是后来补的图,当时的堆内存老年代基本接近96%。而且可以看到FGC有4次,但是停顿时间还凑活。这进一步验证了我们的猜想,有大对象的生成,但是可以回收。

2.3、解决方案

知道了以上结论,和最近做过这个系统需求的小伙伴沟通了一下,都没印象做过什么耗时高的需求。而且这个内存升高的趋势,也不一定是最近才有的,可能一直存在,只不过项目发布频繁,所以没有发现。运维那的Grafana,只存一星期的数据,也看不到是从什么时候出现的这个问题。
针对这种情况。我当时做了2个方案。
第一个,让运维给内存加了报警,超过3个G,就报警。报警之后,从Kibana上查看对应时间段对应系统的日志,重点找一下耗时高的日志。然后用arthas的trace命令看一下耗时高的点
第二个,如果实在找不到耗时高的请求,最差的解决方案,就是按照最近做的需求,挨个方法进行trace,这样慢一点,但是感觉最终可以找到问题

2.4、arthas trace解决问题

幸运的是,内存报警之后,看对应的日志,找到了一个耗时高的接口,长达两秒。然后trace这个接口,就发现了问题所在。
springboot3.2.1 gateway cpu 异常,springboot,性能优化
接口耗时高达两秒,有一个方法占用了84%的耗时,看这个方法的实现,是从数据库里加载几个月的数据,进行业务校验。最开始上线,数据不多,后面数据涨的很快,目前拿到的数据量在150万左右。

2.5、总结

回顾一下整个排查过程,有几个点说一下
1)、写方法一定要注意数据动态增长的情况,比如此例,数据后期增长较快。不能只考虑当时的数据。
2)、有个疑问,就算对象不可达了,正常来说也可以从MAT里看到点相关东西才对,但是翻了很久,啥也没看到,MAT的使用还要再看看,感觉是遗漏了细节
3)、还有个疑问,虽然对象确实很大,但是可以回收,那rancher上看到的内存为啥还会这么高呢?这也是一个疑问点,需要找时间了解一下rancher文章来源地址https://www.toymoban.com/news/detail-826666.html

到了这里,关于springboot应用,cpu高、内存高问题排查的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Java应用堆外内存泄露问题排查

    最近有个java应用在做压力测试 压测环境配置: CentOS系统 4核CPU 8g内存 jdk1.6.0_25,jvm配置-server -Xms2048m -Xmx2048m 出现问题如下 执行300并发,压测持续1个小时后内存使用率从20%上升到100%,tps从1100多降低到600多。 首先使用top命令查看内存占用如下 然后查看java堆内存分布情况,查

    2024年02月12日
    浏览(37)
  • 【Spring Cloud Gateway】⑥SpringBoot3.x集成SpringDoc指南

    Spring Cloud Gateway 使用 Netty 作为嵌入式服务器,并基于响应式 Spring WebFlux 。做为微服务网关,多个微服务把 API 挂在 Gateway 上,如果查看某个 API 的 Swagger 还要去各个子微服务中去查看,就很不方便,如果能在 Gateway 上直接查看各个微服务的 API 文档,会方便很多,本文以截至

    2024年02月14日
    浏览(43)
  • java 应用cpu飙升(超过100%)故障排查

    害。。。 昨天刚写完一份关于jvm问题排查相关的博客,今天线上项目就遇到了一个突发问题。 现象是用户反映系统非常卡,无法操作。 然后登录服务器查看发现cpu 一直100%以上。 发现线上pid 29737的 java应用cpu达到100% 输入上述命令,然后按H显示cpu最高排名的线程。可以看到

    2023年04月26日
    浏览(57)
  • 【面试】线上 CPU 100% 问题排查

    回答套路一般为:线上服务器没有排查过,线上服务器只有运维才有操作权限。在平时开发的时候,在测试服务器上排查过。 2.1、将代码打包成 jar 包 参考: 点我 2.2、传到服务并运行 运行好的效果如下 3.1、拿到进程 id 通过 top 命令,就可以看到让 cpu 100% 的进程 id,pid 就是

    2024年02月11日
    浏览(50)
  • 【记一次线上事故的排查思路】- CPU飙升问题排查

    由于项目排期较紧,临时从其他组调来三个开发资源帮我一起做项目,难免上线的时候大家的需求一块上线。 问题来了,上线三天后,线上CPU总是莫名奇妙的突然飙升,飙升后CPU并未降下来,而是一直处在高点。 由于是线上导致的问题,CPU超限后,会自动重启项目,未能保

    2024年01月23日
    浏览(49)
  • 【已解决】nginx 502 Bad Gateway 问题排查

    访问网站或请求接口时,出现: 日志一般放在/var/log/nginx下面。 跑流水线的话一般部署日志在控制台可以直接看到(我遇到的一次就是构建包下载下来大小为0kb,md5校验也不通过) 源码安装的nginx配置文件一般在 /usr/local/nginx/conf/nginx.conf/ 不是源码安装的一般在 /etc/nginx/ngi

    2024年02月15日
    浏览(55)
  • CPU 飙高问题排查和解决方法

    摘要 本文档记录了排查 CPU 飙高问题的处理过程和解决方法,从多个方面进行分析和排查。 问题简述 在一个生产环境中发现 CPU 飙高问题,但是无法确定问题的具体原因。 排查方法 使用 jstack 导出 JAVA 进程的线程栈信息,并分析线程栈信息,看能否定位到耗费 CPU 的线程。

    2024年02月07日
    浏览(49)
  • Java线上故障排查(CPU、磁盘、内存、网络、GC)+JVM性能调优监控工具+JVM常用参数和命令

    根据服务部署和项目架构,从如下几个方面排查: (1)运用服务器:排查内存,cpu,请求数等; (2)文件图片服务器:排查内存,cpu,请求数等; (3)计时器服务器:排查内存,cpu,请求数等; (4)redis服务器:排查内存,cpu,连接数等; (5)db服务器:排查内存,cpu,连接数

    2024年02月07日
    浏览(61)
  • Linux系统CPU占用率较高问题排查思路

    作为工程师,在日常工作中我们会遇到 Linux服务器上出现CPU负载达到100%居高不下的情况,如果CPU 持续跑高,则会影响业务系统的正常运行,带来企业损失。 对于CPU过载问题通常使用以下两种方式即可快速定位: 方法一 第一步:使用 top命令,然后按shift+p按照CPU排序 找到占

    2024年02月07日
    浏览(33)
  • 排查Docker容器Java程序CPU过高问题以及处理方法

    因为Docker里java程序运行环境是用的jre,没有top和jstack命令,所以要在容器里安装top和jattach,来查看和导出线程信息。 系统:Debian10 镜像:openjdk:8u275-jre-slim-buster 容器ID:99abe55a98dc 一.安装top:     1.进入容器:       2.因为官方镜像地址太慢,所以 修改源地址:https://develop

    2024年02月11日
    浏览(67)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包