|
1、首先检查测试环境
2、检查测试脚本问题，比如前面请求失败后面请求照发导致的错误
3、niginx的work_connection配置
4、由于系统limits open files 限制导致
一。端口不够用
压测的线程数过多时，或者线程没有被及时释放，会导致系统开放的TCP/IP连接端口已达到最大限制，jmeter会直接报错。
【报错信息】：java.net.BindException：Address already in use.
【原因分析】：Windows提供给TCPIP连接的端口为1024-5000，并且要四分钟左右循环回收，这就导致我们短时间内频繁调用大量请求时，端口将被占满。
【解决方案】：
1.打开注册表：在cmd（win+R）中输入regedit，打开注册表；
2.设置系统参数：最大端口连接数。
①找到系统参数设置项：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
②右击parameters，添加一个新的DWORD，参数名为MaxUserPort；
③双击MaxMaxUserPort，输入数值为65534，基数选择十进制；
④重启电脑！重启电脑！重启电脑
二、socket closed
【原因分析】：线程数已达到瓶颈。
【解决方案】
1.循环创建线程时，勾选keep-alive，可以复用线程。
2.扩大被测程序的线程池大小。（程序出现瓶颈时）
三。内存不足
【异常现象】：jmeter安装目录下产生大量很大的.hprof文件。
【原因分析】：这种.hprof文件的产生是内存泄露引起的。
【解决方法】：
1.升级jmeter压测机的硬件配置，增加内存空间；
2.修改jmeter的系统参数。
①打开jmeter.bat文件；
②修改jmeter压测机的内存使用大小：
set HEAP=-Xms3g -Xmx3g -XX:MaxMetaspaceSize=768m（默认是1g，修改为3g）
3.检测被测程序，查找被测的软件程序是否存在内存泄露。
四。带宽瓶颈
【现象】：jmeter执行结果中出现了大量请求超时，但是被测程序的服务器却没有保错日志的情况。
【分析】：可能是主控机的带宽达到了瓶颈。
【解决方法】：
1.升级主控机的硬件配置，扩大带宽值，如：从100MB→500MB；
2.均分多个主控机，避免单主控机远程的执行机数量过多，最好控制在10个以内。
分布式测试有一些基本限制。 官方文档中有提到以下几项：
1.由于没有代理的情况下RMI无法跨子网通信； 因此，分布式压测时，JMeter的所有执行机最好放在同一网段。
2.从2.9版开始，JMeter将剥离响应数据的所有测试结果发送到控制台，这能够减少对网络IO的影响。 确保监视网络流量，以免引起流量争用情况。
3.单个JMeter客户端在处理器为2-3 GHz CPU的主机上运行时，可以处理1000-2000个线程，具体取决于测试的类型。
（这个也取决于业务流程的复杂程度，如果业务流程中有涉及到长连接时，实测单个jmeter客户端只能较好的支持800-1000个线程）
六。建议
定期重启压测机，最好每次压测前都重启一下电脑。
定期清理jmeter生成的日志文件：jmeter.log & jmeter-server.log（安装目录下）。
分布式部署时，一台主控机最好只控制10台以内的执行机，避免主控机的带宽和内存达到瓶颈。
压测时需要监控下压测机的CPU、内存、网络和IO的资源使用情况。
|