jmeter常见错误及解决方法

jmeter常见错误:java

 
  • 错误一:
    Response code: Non HTTP response code: java.net.SocketTimeoutException
    Response message: Non HTTP response message: connect timed out

查看Load time的时间要大于request设置的connect time out时间,因此抛出该异常。多是因为服务端有较多请求正在处理(且处理时间较长),致使JMeter不能链接上服务器而产生的。apache

  • 错误二:
    Java.NET.BindException: Address already in use: connect

缘由:短期内new socket操做不少,而socket.close()操做并不能当即释放绑定的端口,而是把端口设置为TIMEWAIT 状态,过段时间(默认240s)才释放,(用netstat -na能够看到),最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ,这段区间在1024-5000之间)
解决方法:在运行JMeter agent的机器上,添加注册表条目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort 65334
TcpTimedWaitDelay 30windows

  • 错误三:
    java.lang.OutOfMemoryError: Java heap space

缘由:观察运行jmeter机器的内存,占用较高,超过了jmeter设置的内存上限。
解决方案:修改jmeter配置文件,调整内存可用的范围服务器

修改/bin/jmeter.bat文件:找到这2行
set HEAP=-Xms256m -Xmx256m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
改成:
set HEAP=-Xms1024m –Xmx2048m(最大值不能超过系统内存的1/2)
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m网络

  • 错误四:
    Response code: Non HTTP response code: java.net.SocketTimeoutException
    Response message: Non HTTP response message: Read timed out

发生该错误时,jmeter已经链接上服务器,查看load time没有超过设定的request timeout时间,错误可能的缘由是,服务器那边未处理该线程的请求,或者为保证服务能力,断掉了链接。
为了验证该猜测,持续大于半小时向服务器发送该并发数量的请求,一段时间后,request收到503的response,证实猜测。并发

  • 错误五:
    Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:

缘由:分布式测试时,server和agent之间的链接有问题。单个机器排查后,发现是某个agent机器安装了多个网卡,rmi远程的时候找的是虚拟机的网卡,致使链接失败。
解决方案:禁掉不使用的虚拟机网卡,测试以后再恢复。socket

jmeter脚本运行的过程当中,服务器性能参数没有明显变化(CPU,内存,I/O),但request的响应时间很长。tcp

缘由:观察jmeter agent机器网络使用状况,网络使用持续达到带宽的限制峰值。request 发送的过程当中pending在网络中,实际并发的request并无同一时间到达服务器,因此服务器没有明显变化。
解决方案:提升jmeter agent机器网络带宽。分布式

  • 错误六:

Connection timed out: connect工具

 java.net.ConnectException: Connection timed out: connect

 at java.net.DualStackPlainSocketImpl.connect0(Native Method)

  at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)

  at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)

  at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)

  at java.net.AbstractPlainSocketImpl.connect(Unknown Source)

  at java.net.PlainSocketImpl.connect(Unknown Source)

  at java.net.SocksSocketImpl.connect(Unknown Source)

  at java.net.Socket.connect(Unknown Source)

  at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:121)

  at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)

  at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:318)

  at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:114)

 at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)

 at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)

 at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)

 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:654)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:413)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.followRedirects(HTTPSamplerBase.java:1542)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1636)

 at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:519)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:493)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)

 at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491)

 at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425)

 at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254)

 at java.lang.Thread.run(Unknown Source)

缘由分析

多是由于端口号耗尽,通常一台服务器的端口号最可能是65535个,建议使用该命令分别查看下压测机与服务器的端口使用状况,netstat -nat|grep -i 8080|wc -l,若是这个个数在6w左右,那可能就是端口号用尽,同时查看下大多数的端口状态,应该都是time_wait状态
解决方案:
若是是压测机,端口号用尽,那就增长压测机,使用jmeter分布式压测(jmeter默认开启keep_alive的)
若是数服务器,端口号用尽,最大的多是服务器端开了短连接,把短连接配置变成长链接便可
由于若是服务器端是短连接,当jmeter每发起一个请求就会创建一次tcp三次握手,传输完数据后,链接其实没有关,链接状态是time_wait,下个请求来了,会从新开启一个新的端口,创建tcp三次握手,传输数据....,这样随着请求的愈来愈多,端口就会变得愈来愈少,因此端口很快耗尽,并且大多数端口都处于time_wait状态,若是服务器端也支持长链接,那么下次请求来了,就会在上次请求的通道上继续传输,端口使用率大大的下降,就有效的避免了端口耗尽问题。

 

缘由:Jmeter默认禁掉了运行过程当中每一个request的具体response信息收集,只保留了status。
解决方法:修改jmeter.properties文件中Results file configuration。把全部和response相关False的项改成True。运行后将输出保存.jtl文件中。添加tree监听器,过滤只显示error request,能够查看到request和response的具体信息,从而判断出错缘由。

tree report中显示socket time out相关的错误,如何判断是jmeter工具的缘由,仍是服务器的缘由。

相关文章
相关标签/搜索