【性能分析】分析JVM出现的内存泄漏的性能故障

分析JVM出现的内存持续增加的性能故障手册

前言

本文通过常见的性能文件为例,提供简单清晰的思路去快速定位问题根源,从而可以快速解决性能故障。

性能问题介绍

在性能测试工作中针对Java程序最重要的是要关注JVM的内存消耗情况,JVM的内存消耗情况源于gc情况。YGC的不稳定以及YGC的太频繁都会增加CPU等资源的使用。以典型的订购业务的性能问题为例介绍如何分析这类问题:

订购业务在大多数现场性能测试阶段都会发现性能问题,目前V81版本在基于去掉流程实例后,在进行长时间的稳定性测试发现随着稳定的压力,业务响应时间是越来越长。

性能问题分析

上面的问题是一种常见的性能问题,导致JVM内存增加的根本原因就是由于某个大的对象存活时间比较长,占用Yang区和Old区空间比较大,从而引发YGC很频繁同时也伴随着FGC。

分析问题步骤:

  1. 监控JVM的内存消耗

很明显JVM消耗会超过3g这个是不正常的

  1. 分析gc情况

使用jstat指令:jstat -gcutil pid

可以发现YGC是不断增加

详细分析YGC的情况将打印的gc.log使用GCViewer分析工具分析:YGC太频繁

  1. 分析具体哪些对象导致

定位JVM的gc回收不正常后,需要进一步分析是哪些对象占用比较大。此时会有很多方式,但是强烈不建议你抓dump(如果是现网需要禁止抓dump会造成业务长时间的中断),建议使用:jmap – histo pid

从上图可以发现:

com.ztesoft.zsmart.bss.cc.abe.profile.SubsUppInst 这个对象实例大概占了0.5g。

然后进一步定位:jmap -histo:live pid

所以问题基本定位:

业务侧先分析下为什么很低的TPS会有这么多的SubsUppInst 对象。 主要是这个引起的GC波动,问题其实已经明确了。

  1. 性能问题分析

目前V81版本在基于去掉流程实例后,在进行长时间的稳定性测试发现随着subs_upp_inst个性化实例表单个subs_id对应的记录不断增加后,程序对于JVM内存的消耗是越来越多,会引起YGC次数是越来越频繁,同时也会出现FGC。为了保证系统长时间的稳定运行是一定要避免FGC,同时YGC的回收要趋于稳定。因为YGC的越频繁,也就会对于CPU消耗会明显增加,同时影响业务响应时间。

  1. 性能问题优化点

性能问题分析如下:

A. 如果不会有同订户下,订购几百次的场景,那么这个性能问题就不会出现
B. WsModUserIPP接口,如果wom需求没有针对IPP进行修改,删除操作,这个性能也不会出现 (需要简单优化下代码)
C. 不使用公共提供的subs_upp_inst捞取逻辑,原有的逻辑是将subs_id下所有生效的ipp都会捞出来给定制,然后定制开发考虑是否需要过滤。修改需要新开发接口在捞取的时候就过滤掉捞取的数据量(取第一条匹配subsId,offerId和state的记录)。除此之外在下订单和订购完成后多出代码都是全捞的记录,所以全量走查后全部改掉。

问题总结:

  1. 需要你对JVM有一定的了解,需要知道引起YGC和FGC的原理
  2. 需要掌握常规的gc日志抓取手段
  3. 需要掌握分析gc.log的分析工具GCViewer
  4. 需要掌握jstat和jmap的常规命令,需要知道指令对业务性能影响程度
  5. 需要掌握订购业务逻辑

以上以案例介绍针对这类问题如何去分析。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值