一个项目中内存问题的具体分析

本文记录了在性能测试中遇到的高频率Full GC问题及内存泄漏现象,通过调整堆大小、优化脚本关联、改进登录方式等手段,有效降低了GC频率,解决了内存持续上涨的问题。

最初的问题是使用jstat -gcutil发现full gc的发生次数达到了每分钟130次,改变heap size的大小从1024M到4096M. FULL GC的次数下降到了每5分钟一次。可以接受。

在执行5个小时的混合场景时,使用jstat -gcutil 统计,FULL GC的发生次数越来越频繁。

同时用jconsole监控的图如下所示:

可以从图中看出,堆内存的使用不断增长,最终会超出4G的范围,造成连接失败。

经过查看日志,发现是我的脚本中少做了关联,造成了ID找不到。过错啊,写完脚本居然都没有做关联就开始跑场景了。

做完关联后继续跑场景。
结果跑完一段时间的场景后,server变成了warning的状态。不能正常提供服务了。

开发做了修改。结果响应时间的图就变成了这样

 后来经过确认,发现脚本不是记过录制的,而是直接通过写url来访问的,后来把报表改成了录制的方式,再重新跑,响应时间就比较平稳了。但是内存还是会一直上涨。

因为之前有测试的先例。把之前的脚本拿过来比对了一下。

改为从平台登录的方式,内存在涨到顶点之后有所下降。Jconsole的使用图为

 

而数据库的进程图为

在运行过程中,服务器挂掉

转载于:https://www.cnblogs.com/villadom/p/3978730.html

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值