性能测试瓶颈分析举例

性能测试瓶颈分析举例

ID:43613747

大小:226.40 KB

页数:5页

时间:2019-10-11

性能测试瓶颈分析举例_第1页
性能测试瓶颈分析举例_第2页
性能测试瓶颈分析举例_第3页
性能测试瓶颈分析举例_第4页
性能测试瓶颈分析举例_第5页
资源描述:

《性能测试瓶颈分析举例》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、在性能测试过程中,瓶颈犹如功能测试的bug,瓶颈的分析犹如bug的定位。性能测试工程师好比医生,看到病象,定位病因。性能瓶颈的定位更像庖丁解牛,层层解剖,最后定位问题之所在。下面分享一个内存泄漏的瓶颈分析。病象:TPS波动非常大;狂打超时日志;偶尔有500错误。看到这个现象,其实说明不了什么问题,就象人咳嗽,不一定是感冒,可能是上火,嗓子发炎。但是看到这个现象至少说明系统是有性能问题存在,我们就要进一步进行分析,看看问题到底在哪?用jconsole监控内存,发现内存使用如图1"灿I«■me泰大■tmcot

2、te)mzrar补弁图仁内存使用情况图从图1中,我们可以很清晰的看到内存使用不正常,FGC非常频繁,差不多5分钟进行一次,而且内存回收不彻底,每次回收在1G左右徘徊。到这里我们已经可以定位是内存问题,导致了我们看到的TPS波动人,FGC频繁,超时严重等等一系列现象。那么是谁吃了我的内存???用简单的jstat命令查看系统GC情况,看到情况如图2所示99999ob33337752664488033344445566899905555555655555555111-111TOz/119226UOj517580

3、865/8O3O876bo1088880030005500599009在图2的绿色框标注,我们可以很清晰的看到进行一次FGC,内存只回收12%左右,回收很不彻底,而且FGC的时间持续5秒。内存回收不彻底,肯定是有些方法霸占了内存不释放,导致系统频繁FGC来进行回收。那么谁是真正的凶手呢??用jmap命令对内存使用进行分析,发现情况如图3所示2:4:6418532205393024java.util.concurrent.ConcurrentHashMap$Segment6418969154055256ja

4、va.util.concurrent」xks・RQentrantLock$NonfairSync6418532104951032[Ljava.util.concurrent.ConcurrentHashMap$HashEntry;图3通过FGC前后的内存使用进行比对,发现这三个方法快速占用内存从最少到最多,而且回收不掉,始终霸占着前几位。再通过其他工具分析,看看这三个是不是真正的凶手。用MAT分析工具进行分析,图4所示l2Tjzutil,concurrent.locks・ReentrantLockSWon

5、fairSync[cjjev>utilconcurr

6、nt£]607#0utilKashtableut11.ArrayLxst503,5-l&ncckTraceElament405,&util,concurrent・ConcurrentHashMap$HashEntry379,6lane.r

7、。

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。