性能文章>Java项目线上CPU内存过高问题排查案例>

Java项目线上CPU内存过高问题排查案例转载

1月前
176801

正文

问题

下面是线上机器的cpu使用率,可以看到从4月8日开始,随着时间cpu使用率在逐步增高,最终使用率达到100%导致线上服务不可用,后面重启了机器后恢复。

4C81CD01-AE77-44F2-8974-292D24D02867.png


排查思路

简单分析下可能出问题的地方,分为5个方向:

  • 系统本身代码问题
  • 内部下游系统的问题导致的雪崩效应
  • 上游系统调用量突增
  • http请求第三方的问题
  • 机器本身的问题


开始排查

查看日志,没有发现集中的错误日志,初步排除代码逻辑处理错误。

首先联系了内部下游系统观察了他们的监控,发现一切正常。可以排除下游系统故障对我们的影响。

查看provider接口的调用量,对比7天没有突增,排除业务方调用量的问题。

查看tcp监控,TCP状态正常,可以排除是http请求第三方超时带来的问题。

查看机器监控,6台机器cpu都在上升,每个机器情况一样。排除机器故障问题。即通过上述方法没有直接定位到问题。

 

解决方案

1、重启了6台中问题比较严重的5台机器,先恢复业务。保留一台现场,用来分析问题。

2、查看当前的tomcat线程pid。

296575E2-C9B1-4BC2-B0BD-BFD26C76797E.png

3、查看该pid下线程对应的系统占用情况。top -Hp 384

C4C2E089-F28A-45AC-825F-EC6B82990CA5.png

4、发现pid 4430 4431 4432 4433 线程分别占用了约40%的cpu

5、将这几个pid转为16进制,分别为114e 114f 1150 1151

6、下载当前的java线程栈 sudo -u tomcat jstack -l 384>/1.txt

7、查询5中对应的线程情况,发现都是gc线程导致的

2DD05148-C2A8-41F1-995A-1B701D5610A4.png

8、dump java堆数据

 

sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384

 

9、使用MAT加载堆文件,可以看到javax.crypto.JceSecurity对象占用了95%的内存空间,初步定位到问题。

96E851CC-6D80-499A-BD83-F92D61EE2791.png

63C64CE0-F9BF-47AE-9088-CDD0946A4EA1.png

查看类的引用树,看到 BouncyCastleProvider 对象持有过多。即我们代码中对该对象的处理方式是错误的,定位到问题。

 

代码分析

我们代码中有一块是这样写的

E72E0B6A-8885-4E70-A6E8-9BC19A113976.png

这是加解密的功能,每次运行加解密都会new 一个BouncyCastleProvider对象,放到Cipher.getInstance()方法中。

看下Cipher.getInstance()的实现,这是jdk的底层代码实现,追踪到JceSecurity类中

4F6314D1-FB18-44F0-B9D4-94A65486F82E.png


verifyingProviders 每次put后都会remove,verificationResults只会put,不会remove。

9FA07762-736E-472C-84BF-1C68022BCA80.png


看到verificationResults是一个static的map,即属于JceSecurity类的。所以每次运行到加解密都会向这个 map put 一个对象,而这个map属于类的维度,所以不会被GC回收。这就导致了大量的new的对象不被回收。

 

代码改进

将有问题的对象置为static,每个类持有一个,不会多次新建。

 

本文小结

遇到线上问题不要慌,首先确认排查问题的思路:

  • 查看日志
  • 查看CPU情况
  • 查看TCP情况
  • 查看java线程,jstack
  • 查看java堆,jmap
  • 通过MAT分析堆文件,寻找无法被回收的对象
分类:标签:
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

从猫蛇之战再看内核戏CPU
连续写了几天的代码,有些疲倦,吃过晚饭,换个工作方式,继续和大家聊猫蛇之战。蛇不仅丑陋,而且可能伤人害命,是邪恶的象征。猫与蛇战,代表着讨伐奸邪,是正义之战。猫与蛇战,技艺娴熟,举重若轻,叫人拍手叫绝
那些吃CPU的大户
最近沉浸在代码的世界里,处于两耳不闻窗外事的状态。今晚偶有闲暇,看了一眼任务管理器,IDLE进程的时间居然有800多小时,还有多个进程的CPU净时间达到小时级别。如下图所示,IDLE进程的CPU净时间
记一次线上服务CPU 100%的处理过程
告警正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。赶紧从会上下来,SSH登录服务
又一次生产 CPU 高负载排查实践
前言前几日早上打开邮箱收到一封监控报警邮件:某某 ip 服务器 CPU 负载较高,请研发尽快排查解决,发送时间正好是凌晨。其实早在去年我也处理过类似的问题,并记录下来:《[一次生产 CPU 100%
什么会导致Java应用程序的CPU使用率飙升?
问题 无限循环的while会导致CPU使用率飙升吗?经常使用Young GC会导致CPU占用率飙升吗?具有大量线程的应用程序的CPU使用率是否较高?CPU使用率高的应用程序的线程数是多少?处于BLOC
怎么排查CPU飙升
怎么排查CPU飙升线上有些系统,本来跑的好好的,突然有一天就会出现报警,CPU使用率飙升,然后重启之后就好了。例如,多线程操作一个线程不安全的list往往就会出现这种现象。那么怎么定位到具体的代码范围
这些排查内存问题的命令,你用过多少?
我相信大家都遇到过内存占用率过高的情况,在排查过程中,我们会用到一些命令或工具,下面来看下这些你都用过吗? top 命令首先比较常用的就是 top 命令,是性能监控的常用命令,该命令可以实时显示系统中
使用XPocket插件top_x 解决cpu高及 cpu_load高的一般思路
本文使用了xpocket工具包的插件链接xpocket地址:[https://plugin.xpocket.perfma.com](https://plugin.xpocket.perfma.com)