性能测试之性能问题分析

开始性能测试前需要了解的内容:

  1、项目具体需求。   2、指标:响应时间在多少以内,并发数多少,tps多少,总tps多少,稳定性交易总量多少,事务成功率,交易波动范围,稳定运行时长,资源利用率,测哪些交易,哪些接口,测试哪些场景。   3、环境:生产环境服务器数量,测试环境服务器数量,按照资源配比得出测试指标。   4、协议:系统用什么协议进行通讯。   5、压力机数量:如果并发用户数太多,需要把压力发到不同的压力机,不然可能会存在压力机瓶颈问题,导致tps和响应时间抖动。   6、交易占比:分析线上日志得出tps占比。   7、系统架构:请求流经过哪些环节,压测时监控这些环节。     测试策略:   1、基准:一个用户迭代100次,关注响应时间,事务成功率100%。   2、负载:10个用户跑10分钟,关注响应时间,事务成功率100%。   3、容量:估算一个总tps,根据公式计算出每个交易的pacing和vu,获取系统最大处理能力(最优容量),再令外测出三个梯度作为对比(两组小于最优容量,一组大于最优容量),四组容量VU等差,tps等差,对比每组容量实际占比和测试占比(越接近越能模拟真实场景),关注响应时间,总tps,tps,事务成功率,AP cpu利用率,DB cpu利用率,线程死锁,数据库死锁。   其中响应时间应小于负载测试时间,总tps应约等于预估总tps(相差不超过10是正常的),每个交易的tps应接近预估总tps*占比,事务成功率100%,AP cpu小于60%,DB cpu小于80%。dump线程栈检测是否有线程死锁,查看数据库日志看是否有数据库死锁。   4、稳定性:采取最优容量的80%作为压力持续运行24小时,观察系统长时间运行的性能表现,关注响应时间,tps,总tps,事务成功率,交易总数,观察是否有内存溢出(堆溢出,栈溢出,持久代溢出),cpu利用率是否达标,mem是否不持续增长,是否能正常触发fullgc,gc时间,gc频率, fullgc时间,fullgc频率(重点关注,JVM调优就是为了减少fullgc频率)。           监控:   容量测试和稳定性测试时启动nmon监控。   压测中遇到的性能问题及解决办法: 一、容量测试过程中cpu过高   1、用vmstat实时监控cpu使用情况。很小的压力AP cpu却到了80%多,指标是不能超过60%。   2、分析是use cpu过高还是sys cpu过高,常见的是use cpu使用过高。   3、如果是use cpu使用过高,先把消耗cpu最多的进程找出来(top命令),再找到该线程下消耗cpu过高的是哪几个线程,再把该线程转换成16进制,再用jstack命令来dump线程栈,看这个线程栈在调用什么东西导致use cpu过高。   二、内存溢出(堆溢出、栈溢出、持久代溢出)   1、堆内存溢出   产生的现象:稳定性压测一段时间后,LR报错,日志报java.lang.OutOfMemoryError.Java heap space。      排查手段:        1)用jmap -histo pid命令dump堆内存使用情况,查看堆内存排名前20个对象,看是否有自己应用程序的方法,从最高的查起,如果有则检查该方法是什么原因造成堆内存溢出。   2)如果前20里没有自己的方法,则用jmap -dump来dump堆内存,在用MAT分析dump下来的堆内存,分析导出内存溢出的方法。   解决方式:如果应用程序的方法没有问题,则需要修改JVM参数,修改xms,xmx,调整堆内存参数,一般是增加堆内存。   2、栈内存溢出   产生的原因:稳定性压测一段时间后,LR报错,日志报Java.Lang.*Error。     解决方式:修改jvm参数,将xss参数改大,增加栈内存。                           栈溢出一定是做批量操作引起的,减少批处理数据量。   3、持久代溢出   产生的现象:稳定性压测一定时间后,日志报Java.Lang.OutOfMenoryError.PermGen Space。        解决方式:   1)这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多,将持久代占满导致持久代溢出。   2)修改jvm配置,将XX:MaxPermSize=256参数调大。尽量减少静态变量。   三、线程死锁
  产生的原因:在多线程程序的编写中,如果不适当的运用同步机制,则有可能造成程序的死锁,经常表现为程序的停顿,或者不再响应用户的请求。
       产生的现象:   1、容量测试压测一段时间后,LR报连接超时。   2、造成这种现象的原因很多,比如带宽不够,中间件线程池不够用,数据库连接池不够,连接数占满等都会造成连接不上而报超时错误。        排查手段:   1、jstack命令dump线程栈,搜索线程栈里有没有block,如果有的话就是线程死锁,找到死锁的线程,分析对应的代码。

   jstack -F pid >jts.log(java进程id,可以用jps或者ps aux|grep java 去找),将线程的状态输出到jts.log文件

       值得关注的线程状态有:
       死锁,Deadlock(重点关注)
       执行中,Runnable  
       等待资源,Waiting on condition(重点关注)
       等待获取监视器,Waiting on monitor entry(重点关注)
       暂停,Suspended
       对象等待中,Object.wait() 或 TIMED_WAITING
       阻塞,Blocked(重点关注) 
       停止,Parked

       后置处理:把生成的文件,让开发排查几个重点的状态下的业务代码逻辑

 

四、数据库死锁   产生的现象:容量测试压测一段时间后,LR报连接超时。   排查手段:数据库日志中搜索block,能搜到block的话就是存在数据库死锁,查看对应的sql,优化造成死锁的sql。   五、数据库连接池不释放   产生的现象:容量测试压测一段时间后,LR报连接超时。   排查与解决方式:去数据库查看应用程序到数据库的连接有多少个( show full processlist),假如应用程序里面配置的数据库连接为30,在数据库查看应用程序到数据库的连接也是30,则表示连接池占满了。将配置改成90试试,去数据库看如果连接到了90,则可以确定是数据库连接池不释放导致的。查看代码,数据库连接部分是不是有创建连接但是没有关闭连接的情况。基本就是这种情况导致的,修改代码即可。   六、TPS上不去   产生的现象:压力大的时候tps频繁抖动,导致总tps上不去。查看是否有fullgc(tail -f gc_mSrv1.log | grep full)。        排查手段:   1、pacing时间间隔设置太大也会导致tps上不去,减小pacing时间间隔。   2、单压抖动大的交易,发现很平稳,这时怀疑是不是压力太大导致,所以发容量的时候把压力最大的那只交易分到其他压力机,然后发现tps不抖动了。注意:多台压力机只影响tps抖动,不会影响服务器的cpu。   3、看响应时间有没有超时,看用户数够不够,都在指标内,可以添加用户数。   七、服务器压力不均衡(但相差1%-2%是正常的)   1、跑最优容量的时候,四台APP只有一台cpu超过60%,其他三台都在60%以下。   2、查看服务器是否有定时任务。   3、查看是否存在压力机瓶颈。   4、是否存在带宽瓶颈(局域网不存在此问题)。   5、查看部署的版本,配置是否一样。   6、可能别人也在用这些APP,因为同一台物理机上有很多虚拟机,因为别人先用,资源被别人先占了。        7、前置服务器承担负载调度(Nginx,lvs)分配策略问题   八、fullgc时间太长        产生的原因及排查手段:   1、跑容量和稳定性的时候,出现LR报请求超时错误        2、查看后台日志是fullgc了,看LR几点报的错和日志里fullgc的时间是否对应,fullgc会暂停整个应用程序,导致LR前端没响应,所以报错,这时可以减少old代内存,从而减少fullgc时间,减少fullgc时间LR就不会报错,让用户几乎感觉不到应用程序暂停。   解决方式:四台APP轮流着full gc(部分server fullgc,其他server也会fullgc),这时可以制定策略让不同的server不同时fullgc,或者等夜间交易量少时写定时任务重启服务。   九、LR报连接超时        1、造成这种现象的原因很多,比如数据库死锁、数据库连接池不释放、fullgc时间太长、堆内存溢出、栈内存溢出、持久代溢出、带宽不够,中间件线程池不够用,数据库连接池不够,连接数占满等都会造成连接不上而报超时错误。     注意:   服务器日志为error下测试。   服务启动后几分钟内发压压力会很大,最好是服务启动两三分钟后再开始跑压力。    性能问题分析流程

1、查看服务器的CPU、内存 、负载等情况
2、查看数据库健康状态
3、查看项目日志(查看无特殊现象)
4、查看jvm的gc等情况
5、回滚上一个版本(一般是最后的手段)

上一篇:【java虚拟机】jvm调优原则


下一篇:诊断gc是否正常