网站建设公司-信科网络,在线文档网站源码,wordpress 动画主题,网站建设的功能特点有哪些开始性能测试前需要了解的内容#xff1a; 1、项目具体需求。 2、指标#xff1a;响应时间在多少以内#xff0c;并发数多少#xff0c;tps多少#xff0c;总tps多少#xff0c;稳定性交易总量多少#xff0c;事务成功率#xff0c;交易波动范围#xff0c;稳定运行时…开始性能测试前需要了解的内容 1、项目具体需求。 2、指标响应时间在多少以内并发数多少tps多少总tps多少稳定性交易总量多少事务成功率交易波动范围稳定运行时长资源利用率测哪些交易哪些接口,测试哪些场景。 3、环境生产环境服务器数量测试环境服务器数量按照资源配比得出测试指标。 4、协议系统用什么协议进行通讯。 5、压力机数量如果并发用户数太多需要把压力发到不同的压力机不然可能会存在压力机瓶颈问题导致tps和响应时间抖动。 6、交易占比分析线上日志得出tps占比。 7、系统架构请求流经过哪些环节压测时监控这些环节。 测试策略 1、基准一个用户迭代100次关注响应时间事务成功率100%。 2、负载10个用户跑10分钟关注响应时间事务成功率100%。 3、容量估算一个总tps根据公式计算出每个交易的pacing和vu获取系统最大处理能力最优容量再令外测出三个梯度作为对比两组小于最优容量一组大于最优容量四组容量VU等差tps等差对比每组容量实际占比和测试占比越接近越能模拟真实场景关注响应时间总tpstps事务成功率AP cpu利用率DB cpu利用率线程死锁死锁。 其中响应时间应小于负载测试时间总tps应约等于预估总tps相差不超过10是正常的每个交易的tps应接近预估总tps*占比事务成功率100%AP cpu小于60%DB cpu小于80%。dump线程栈检测是否有线程死锁查看数据库日志看是否有数据库死锁。 4、稳定性采取最优容量的80%作为压力持续运行24小时观察系统长时间运行的性能表现关注响应时间tps总tps事务成功率交易总数观察是否有内存溢出堆溢出栈溢出持久代溢出cpu利用率是否达标mem是否不持续增长是否能正常触发fullgcgc时间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报错日志报lang.OutOfMemoryError.Java heap space。 排查手段 1)用jmap -histo pid命令dump堆内存使用情况查看堆内存排名前20个对象看是否有自己应用程序的方法从最高的查起如果有则检查该方法是什么原因造成堆内存溢出。 2)如果前20里没有自己的方法则用jmap -dump来dump堆内存在用MAT分析dump下来的堆内存分析导出内存溢出的方法。 解决方式如果应用程序的方法没有问题则需要修改JVM参数修改xmsxmx调整堆内存参数一般是增加堆内存。 2、栈内存溢出 产生的原因稳定性压测一段时间后LR报错日志报Java.Lang.StackOverflowError。 解决方式修改jvm参数将xss参数改大增加栈内存。 栈溢出一定是做批量操作引起的减少批处理数据量。 3、持久代溢出 产生的现象稳定性压测一定时间后日志报Java.Lang.OutOfMenoryError.PermGen Space。 解决方式 1)这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多将持久代占满导致持久代溢出。 2)修改jvm配置将XX:MaxPermSize256参数调大。尽量减少静态变量。 三、线程死锁 产生的原因在多线程程序的编写中如果不适当的运用同步机制则有可能造成程序的死锁经常表现为程序的停顿或者不再响应用户的请求。 产生的现象 1、容量测试压测一段时间后LR报连接超时。 2、造成这种现象的原因很多比如带宽不够中间件线程池不够用数据库连接池不够连接数占满等都会造成连接不上而报超时错误。 排查手段 1、jstack命令dump线程栈搜索线程栈里有没有block如果有的话就是线程死锁找到死锁的线程分析对应的代码。 jstack -F pid jts.logjava进程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上不去。查看是否有fullgctail -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、前置服务器承担负载调度Nginxlvs分配策略问题 八、fullgc时间太长 产生的原因及排查手段 1、跑容量和稳定性的时候出现LR报请求超时错误 2、查看后台日志是fullgc了看LR几点报的错和日志里fullgc的时间是否对应fullgc会暂停整个应用程序导致LR前端没响应所以报错这时可以减少old代内存从而减少fullgc时间减少fullgc时间LR就不会报错让用户几乎感觉不到应用程序暂停。 解决方式四台APP轮流着full gc部分fullgc其他server也会fullgc这时可以制定策略让不同的server不同时fullgc或者等夜间交易量少时写定时任务重启服务。 九、LR报连接超时 1、造成这种现象的原因很多比如数据库死锁、数据库连接池不释放、fullgc时间太长、堆内存溢出、栈内存溢出、持久代溢出、带宽不够中间件线程池不够用数据库连接池不够连接数占满等都会造成连接不上而报超时错误。 注意 服务器日志为error下测试。 服务启动后几分钟内发压压力会很大最好是服务启动两三分钟后再开始跑压力。 性能问题分析流程
1、查看服务器的CPU、内存 、负载等情况 2、查看数据库健康状态 3、查看项目日志查看无特殊现象 4、查看jvm的gc等情况 5、回滚上一个版本一般是最后的手段
