【性能测试】- 压测中遇到的性能问题及解决办法

一、测试过程中cpu过高

1、用vmstat实时监控cpu使用情况。很小的压力AP cpu却到了80%多,指标是不能超过60%。

     vmstat 2 (每二秒显示一次系统内存的统计信息)

2、分析是use cpu过高还是sys cpu过高,常见的是use cpu使用过高。

3、如果是sys cpu使用过高,先把消耗cpu最多的进程找出来(top命令),再找到该线程下消耗cpu过高的是哪几个线程,再把该线程转换成16进制,再用jstack命令来dump线程栈,看这个线程栈在调用什么东西导致use cpu过高。

①top -> top -H -p pid -> ②printf '0x%x' tid ->③stack pid | grep tid ->④jstack  pid > dump01

二、内存溢出(堆溢出、栈溢出、持久代溢出)

1、堆内存溢出

1)稳定性压测一段时间后报错,日志报java.lang.OutOfMemoryError.Java heap space。

2)用jmap -histo pid | head -20命令dump堆内存使用情况,查看堆内存排名前20个对象,看是否有自己应用程序的方法,从最高的查起,如果有则检查该方法是什么原因造成堆内存溢出。

3)如果前20里没有自己的方法,则用jmap -dump来dump堆内存(jmap -dump:format=b,file=202007028.dump 105944),在用jvisualvm分析dump下来的堆内存,分析导出内存溢出的方法。

4)如果应用程序的方法没有问题,则需要修改JVM参数,修改xms,xmx,调整堆内存参数,一般是增加堆内存。

2、栈内存溢出

1)稳定性压测一段时间后报错,日志报Java.Lang.StackOverflowError。

2)修改jvm参数,将xss参数改大,增加栈内存。

3)栈溢出一定是做批量操作引起的,减少批处理数据量。

3、持久代溢出

1)稳定性压测一定时间后,日志报Java.Lang.OutOfMenoryError.PermGen Space。

2)这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多,将持久代占满导致持久代溢出。

3)修改jvm配置,将XX:MaxPermSize=256参数调大。尽量减少静态变量。

三、线程死锁

1、容量测试压测一段时间后,压力工具报连接超时。

2、造成这种现象的原因很多,比如带宽不够,中间件线程池不够用,数据库连接池不够,连接数占满等都会造成连接不上而报超时错误。

3、jstack命令dump线程栈,搜索线程栈里有没有block,如果有的话就是线程死锁,找到死锁的线程,分析对应的代码

四、数据库死锁

1、容量测试压测一段时间后,报连接超时。

2、造成这种现象的原因很多,比如带宽不够,中间件线程池不够用,数据库连接池不够,连接数占满等都会造成连接不上而报超时错误。

3、数据库日志中搜索block,能搜到block的话就是存在数据库死锁,找到日志,查看对应的sql,优化造成死锁的sql。

五、数据库连接池不释放

1、容量测试压测一段时间后,报连接超时

2、造成这种现象的原因很多,比如带宽不够,中间件线程池不够用,数据库连接池不够,连接数占满等都会造成连接不上而报超时错误。

3、去数据库查看应用程序到数据库的连接有多少个( show full processlist),假如应用程序里面配置的数据库连接为30,在数据库查看应用程序到数据库的连接也是30,则表示连接池占满了。将配置改成90试试,去数据库看如果连接到了90,则可以确定是数据库连接池不释放导致的。查看代码,数据库连接部分是不是有创建连接但是没有关闭连接的情况。基本就是这种情况导致的,修改代码即可。

六、TPS上不去

1、压力大的时候tps频繁抖动,导致总tps上不去。查看是否有fullgc(tail -f gc_mSrv1.log | grep full)。

2、pacing设置太小也会导致tps上不去,对抖动大的交易多增加点用户即可。

3、tps抖动,单压抖动大的交易,发现很平稳,这时怀疑是不是压力太大导致,所以发容量的时候把压力最大的那只交易分到其他压力机,然后发现tps不抖动了。注意:多台压力机只影响tps抖动,不会影响服务器的cpu。

4、看响应时间有没有超时,看用户数够不够。

七、服务器压力不均衡(相差1%-2%是正常的)

1、跑最优容量的时候,四台AP只有一台cpu超过60%,其他三台都在60%以下。

2、查看服务器是否有定时任务。

3、查看是否存在压力机瓶颈。

4、是否存在带宽瓶颈(局域网不存在此问题)。

5、查看部署的版本,配置是否一样。

6、可能别人也在用这些AP,因为同一台物理机上有很多虚拟机,因为别人先用,资源被别人先占了。

八、fullgc时间太长

1、跑容量和稳定性的时候,出现报请求超时错误,查看后台日志是fullgc了,看几点报的错和日志里fullgc的时间是否对应,fullgc会暂停整个应用程序,导致LR前端没响应,所以报错,这时可以减少old代内存,从而减少fullgc时间,减少fullgc时间就不会报错,让用户几乎感觉不到应用程序暂停。

2、四台AP轮流着full gc(部分server fullgc,其他server也会fullgc),这时可以制定策略让不同的server不同时fullgc,或者等夜间交易量少时写定时任务重启服务。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页