压测前准备:
1.脚本是否正确
2.redis情况(使用redis情况来估算压测的数量)
3.数据库数据量
4.主机cpu和内存情况
5.高锋时间段各方法的访问量:
注: 项目性能是通过qps进行评估的,一个项目的性能qps是上层业务给定的,要求必须达到的,开发人员统计生产环境高峰时间段节点访问量是为了以一定的比例进行并发线程的分配,测试都是并发1000的大小往上增,直到达到要求的qps,项目性能才算合格。
压测过程中:
出现错误率时;
1.查看jmeter的root.log和jmeter.log来确认jmeter这边报的是什么错误
2.查看服务端错误日志,查看是不是调用服务出错
3.如果是找不到服务看是不是zk注册失败
4.查看服务端调用耗时
5.看redis和数据库数据量和内存使用情况,和redis慢查询
6.查看服务所在主机的cpu和内存使用情况
https://blog.csdn.net/supera_li/article/details/45221367
https://www.cnblogs.com/maomaochong123/p/8094233.html
https://www.cnblogs.com/wuchangsoft/p/10212797.html
IO:
https://blog.51cto.com/291268154/1981358
https://www.cnblogs.com/maomaochong123/p/8094233.html
https://blog.51cto.com/291268154/1981358
7.确认是不是jmeter本身的序列化问题
8.看是不是设置的并发,吞吐过大了
9.查看full gc的情况:
10.线程dump监控
jstack -l PID >> 1.txt
https://www.cnblogs.com/wuchangsoft/p/10212797.html
使用jac进行dump文件【包括死锁线程状态】分析:
jac下载地址:https://download.csdn.net/download/yanhhuan/13078231
命令:java -jar jca457.jar 1.txt
1.txt右建->Thread Detail则可以得到线程详细信息
这里基本就显示了各个线程状态分析情况。一般重点查看“等待资源Waiting on condition”、“wait()”、“阻塞Blocked”。这些是引起CPU高,可能是线程执行有死循环。
New: 当线程对象创建时存在的状态,此时线程不可能执行;
Runnable:当调用thread.start()后,线程变成为Runnable状态。只要得到CPU,就执行;
Running:线程正在执行;
Waiting:执行thread.join()或在锁对象调用obj.wait()等情况就会进该状态,表明线程正处于等待某个资源或条件发生来唤醒自己;
Timed_Waiting:执行Thread.sleep(long)、thread.join(long)或obj.wait(long)等就会进该状态,与Waiting的区别在于Timed_Waiting的等待有时间限制;
Blocked:如果进入同步方法或同步代码块,没有获取到锁,则会进入该状态;
Dead:线程执行完毕,或者抛出了未捕获的异常之后,会进入dead状态,表示该线程结束
其次,对于jstack日志,我们要着重关注如下关键信息
Deadlock:表示有死锁
Waiting on condition:等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析,比如线程正在sleep,网络读写繁忙而等待
Blocked:阻塞
Waiting on monitor entry:在等待获取锁
in Object.wait():获取锁后又执行obj.wait()放弃锁
如果jmeter那边出现错误率:
1.查看错误日志查看是不是调用服务出错
2.如果业务耗时过大就看redis和数据库情况
2.查看redis数据量和redis使用情况
3.如果服务有使用数据库,查看数据库数据量和使用情况(可能是数据库处理慢处理不过来,这个啥时候查看数据库使用情况(内存,数据量),重启数据库实例可以释放点内存)
切记:先分析问题,看有哪些原因,再排查看是那些问题