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

通常按照以下思路分析系统的瓶颈，先看业务指标:响应时间、业务错误率、和 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,分析内存最大的对象