new ArrayList 不当导致 CPU 飙升。。

这篇具有很好参考价值的文章主要介绍了new ArrayList 不当导致 CPU 飙升。。。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

来源:juejin.cn/post/7139202066362138654

昨天线上容器突然cpu飙升,也是第一次排查这种问题所以记录一下~

前言

首先问题是这样的,周五正在写文档,突然收到了线上报警,发现cpu占用达到了90多,上平台监控系统查看容器,在jvm监控中发现有一个pod在两个小时内产生了61次youngGc一次fullGc,这个问题特别严重且少见,由于我之前也没有排查过此类问题,所以也是百度,但整个过程也有一些自己的思考,所以跟大家分享一下~

推荐一个开源免费的 Spring Boot 实战项目:

https://github.com/javastacks/spring-boot-best-practice

当时场景

我先给大家看一下一副正常的gc曲线监控(为保密性,我自己按照平台监控画了出来):

正常的jvm监控曲线图

new ArrayList 不当导致 CPU 飙升。。

产生问题的jvm监控曲线图

new ArrayList 不当导致 CPU 飙升。。

可以看的出来,正常情况下该系统很少gc(具体看业务系统使用情况、jvm内存分配),但是在图二中出现了大量异常的gc情况甚至触发了fullGc,所以我当时立马进行了分析。

具体分析

首先异常gc的情况只出现在一个pod上(系统有多个pod),在监控系统找到对应的pod,进入pod内部查看问题原因,排查问题一定要冷静

进入pod之后,输入top查看各linux进程对系统资源的使用情况(因我这是事后补稿,资源使用不高,大家看步骤即可)

new ArrayList 不当导致 CPU 飙升。。

分析资源使用情况在当时的情况下

new ArrayList 不当导致 CPU 飙升。。

当时我的pid为1的进程cpu上到了130(多核)那我认定就是java应用出问题了,control+c退出继续往下走

输入top -H -p pid 通过此命令可以查看实际占用CPU最高的的线程的id,pid为刚才资源使用高的pid号

new ArrayList 不当导致 CPU 飙升。。

出现具体线程的资源使用情况,表格里的pid代表线程的id,我们称他为tid

new ArrayList 不当导致 CPU 飙升。。

我记得当时的tip为746(上述图片只是我给大家重复步骤),使用命令printf "%x\n" 746,将线程tid转换为16进制

new ArrayList 不当导致 CPU 飙升。。

因为我们线程id号在堆栈里是16进制的所以需要做一个进制转换

输入jstack pid | grep 2ea >gc.stack

jstack pid | grep 2ea >gc.stack

new ArrayList 不当导致 CPU 飙升。。

解释一下,jstack是jdk给提供的监控调优小工具之一,jstack会生成JVM当前时刻的线程快照,然后我们可以通过它查看某个Java进程内的线程堆栈信息,之后我们把堆栈信息通过管道收集2ea线程的信息,然后将信息生成为gc.stack文件,我随便起的,随意

当时我先cat gc.stack 发现数据有点多在容器里看不方便,于是我下载到本地浏览,因为公司对各个机器的访问做了限制,我只能用跳板机先找到一台没用的机器a,把文件下载到a然后我再把a里的文件下载到本地(本地访问跳板机OK),先输入python -m SimpleHTTPServer 8080,linux自带python,这个是开启一个简单http服务供外界访问

new ArrayList 不当导致 CPU 飙升。。

然后登录跳板机,使用curl下载curl -o http://ip地址/gcInfo.stack

为方便演示,我在图中把ip换了一个假的

new ArrayList 不当导致 CPU 飙升。。

之后用同样的方法从本地下载跳板机就可以了,记得关闭python开启的建议服务嗷

把文件下载到了本地,打开查看编辑器搜索2ea,找到nid为2ea的堆栈信息

new ArrayList 不当导致 CPU 飙升。。

之后找到对应的impl根据行数分析程序

发现是在文件异步导出excel的时候,导出接口使用了公共列表查询接口,列表接口查询数据最多为分页200一批,而导出数据量每个人的权限几万到十几万不等

new ArrayList 不当导致 CPU 飙升。。

并且该判断方法使用了嵌套循环里判断,且结合业务很容易 get 不到 value,Java 下的new ArrayList 就是返回一个 List 集合(好像不用说这么细 (;一_一 ),在整个方法结束之前,产生的 lists生命周期还在所以发生多次gc触发重启之后还影响到了别的pod。然后对代码进行了fix,紧急上线,问题解决~

结束语

遇到生产问题,大家不要害怕,遇到问题先保证服务是否可用,然后通过有限的信息层层解析,找出最终的问题。如果你会 arthas,排查起来会更轻松!

近期热文推荐:

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!

5.《Java开发手册(嵩山版)》最新发布,速速下载!

觉得不错,别忘了随手点赞+转发哦!文章来源地址https://www.toymoban.com/news/detail-637396.html

到了这里,关于new ArrayList 不当导致 CPU 飙升。。的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 一次Python本地cache不当使用导致的内存泄露

    近期一个大版本上线后,Python编写的api主服务使用内存有较明显上升,服务重启后数小时就会触发机器的90%内存占用告警,分析后发现了本地cache不当使用导致的一个内存泄露问题,这里记录一下分析过程。 该cache大概实现代码如下: 如上述代码,该LocalCache核心在于一个存储

    2024年02月11日
    浏览(40)
  • K8s攻击案例:RBAC配置不当导致集群接管

    01、概述 Service Account本质是服务账号,是Pod连接K8s集群的凭证。在默认情况下,系统会为创建的Pod提供一个默认的Service Account,用户也可以自定义Service Account,与Service Account关联的凭证会自动挂载到Pod的文件系统中。 当攻击者通过某个web应用获取到一个Pod权限时,如果RBAC权

    2024年02月02日
    浏览(46)
  • JVM-Cpu飙升排查及解决

    https://blog.csdn.net/m0_37542440/article/details/123679011 1. 问题情况 在服务器上执行某个任务时,系统突然运行缓慢,top 发现cpu飙升,一度接近100%,最终导致服务假死。 2. 问题排查 1. 执行 “top” 命令:查看所有进程占系统cpu的排序,极大可能排第一的就是自己的java进程,pid就是进

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

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

    2023年04月26日
    浏览(60)
  • STM32 定时器配置不当导致误差(精度)偏大的问题发现与解决

    通用定时器TIM2/3/4/5,PWM输出1Khz的波形 一开始初始化代码如下: 示波器端查看效果如下:误差在5.64‰ 修好初始化代码如下: 示波器端查看效果如下:误差在0.2‰ Over!

    2024年01月16日
    浏览(52)
  • Elasitcsearch CPU 使用率突然飙升,怎么办?

    本系列文章介绍如何修复 Elasticsearch 集群的常见错误和问题。 这是系列文章的第二篇,主要探讨:Elasitcsearch CPU 使用率突然飙升,怎么办? 线上环境 Elasticsearch CPU 使用率飙升常见问题如下: ——来自《死磕Elasticsearch 知识星球》 Elasticsearch 使用线程池来管理并发操作的 CP

    2024年02月05日
    浏览(80)
  • Java线上服务CPU、内存飙升问题排查步骤!

    作为一名从事Java开发快一年的程序员,在线上经常碰到 某个模块的Pod发出CPU与内存告警的问题 ,而这些问题会导致系统响应缓慢甚至是服务不可用。一般情况下可以通过 重启 或者 调高Pod的资源量或者增加Pod数量 暂时解决问题,但这是治标不治本的,只有找到问题发生的原

    2024年02月16日
    浏览(49)
  • 深度翻页导出导致慢SQL,mysqlCPU飙升优化方案

    慢SQL原因分析: 1.深度翻页 2.多表JOIN 3. 大IN 4. id倒排序 本文针对深度翻页的优化进行探讨 将limit   offset, pageSize的方式改成 id xx limit pageSize. 这样能走Id索引,提高速度。 缺点:不能使用多线程,入参ID从上页结果。 基于 方案1再优化, 将limit   offset, pageSize 的方式改成 i

    2024年02月09日
    浏览(30)
  • MySQL数据库CPU飙升到100%解决方案

    当cpu飙升到100%时,先用操作系统命令top命令观察是不是mysqld占用导致的,如果不是,找出占用高的进程,并进行相关处理。 进入mysql命令行 查看慢查询SQL是否启用:ON是开启,OFF是关闭。 show variables like ‘log_slow_queries’; 开启慢查询日志 set global log_slow_queries = on; 如果是mysql

    2024年02月16日
    浏览(48)
  • vue大坑:v-for的key以及props传参不当导致的闭包

    为什么props传参在模版中使用没问题,在函数中使用不变化 场景 当我们点击上方的月份时,会改变下方加载的卡片信息 代码: 父组件: 字组件 流程: 当我们点击月份的时候,会加载对应月份的子组件卡片 当我们点击某一个子组件的时候,会判断是否跳转 问题: 如果我们

    2023年04月14日
    浏览(42)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包