小记性能测试瓶颈挖掘与分析

一般按照如下思路分析系统的瓶颈，先看业务指标:响应时间、业务错误率、和 tps 是否满足目标。
如果其中有一个有异常,可以先排除施压机和外围依赖系统是否有瓶颈,如果没有,关注网 络、db 的性能和连接数,最后关注系统本身的指标:
1. 硬件：磁盘是否写满、内存是否够用、cpu的利用率、平均load值
2. 软件： 操作系统版本、jdk版本、jboss容器以及应用依赖的其他软件版本
3. JVM内存管理和回收是否合理
4. 应用程序本身代码

应用系统本身的瓶颈

应用系统负载分析：

• CPU使用率
• 内存使用率
• Load 一般cpu的使用率应低于50%,如果过高有可能程序的算法耗费太多cpu,或者 某些代码块进行不合理的占用。Load值尽量保持在cpuS+2 或者cpuS*2,其中 cpu 和 load 一般与并发数成正比
• 内存可以通过 2 种方式来查看: 1) 当 vmstat 命令输出的 si 和 so 值显示为非 0 值,则表示剩余可支配的物理内存已经严重不足,需要通过与磁盘交换内容来保持系统的 稳定 ; 由于磁盘处理的速度远远小于内存,此时就会出现严重的性能下降 ;si 和 so的值越大,表示性能瓶颈越严重。2) 用工具监控内存的使用情况,如果出现内存占用一直上升的趋势有可能系统内存占满的情况
• 如果出现内存占用一直上升的趋势,有可能系统一直在创建新的线程,旧的线程没有销毁; 或者应用申请了堆外内存,一直没有回收导致内存一直增长.

JVM 瓶颈分析:

1.Gc 频率分析

对于 java 应用来说,过高的 GC 频率也会在很大程度上降低应用的性能。即使采用了并发 收集的策略,GC 产生的停顿时间积累起来也是不可忽略的,特别是出现 cmsgc 失败,导致 fullgc 时的场景。下面举几个例子进行说明:
Cmsgc 频率过高,当在一段较短的时间区间内,cmsGC 值超出预料的大,那么说明该 JAVA 应用在处理对象的策略上存在着一些问题,即过多过快地创建了长寿命周期的对象,是需要改进的。或者 old 区大小分配或者回收比例设置得不合理,导致 cms 频繁触发,下 面看一张 gc 监控图(蓝色线代表 cmsgc)

由图看出:cmsGC 非常频繁,后经分析是因为 jvm 参数 -XX:CMSInitiatingOccupanc yFraction 设置为 15,比例太小导致 cms 比较频繁,这样可以扩大 cmsgc 占 old 区的比例,降低 cms 频率注。调优后的图如下:

2.fullgc 频繁触发

当采用 cms 并发回收算法,当 cmsgc 回收失败时会导致 fullgc:
fullgc 的耗时非常长,在 6~7s 左右,这样会严重影响应用的响应时间。
经分析是因为 cms 比例过大,回收频率较慢导致,调优方式:调小 cms 的回比例,尽早触 发 cmsgc,避免触发 fullgc
从上面 2 个例子看出 cms 比例不 是绝对的,需要根据应用的具体情况来看,比如应用创建的对象存活周期长,且对象较大,可以适当提高 cms 的回收比例。

3.疑似内存泄露

分析:每次 cmsgc 没有回收干净,old 区呈上升趋势,疑似内存泄露 最终有可能导致 OOM,这种情况就需要 dump 内存进行分析: a.找到 oom 内存 dump 文件,具体的文件配置在 jvm 参数里: -XX:HeapDumpPath=/ home/admin/logs b.-XX:ErrorFile=/home/admin/logs/hs_err_pid%p.log c.借助工具:MAT,分析内存最大的对象