jmeter常見錯誤及解決方法

jmeter常見錯誤：

 

• 錯誤一：
  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不能鏈接上服務器而產生的。

• 錯誤二：
  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 30

• 錯誤三：
  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遠程的時候找的是虛擬機的網卡，致使鏈接失敗。
解決方案：禁掉不使用的虛擬機網卡，測試以後再恢復。

jmeter腳本運行的過程當中，服務器性能參數沒有明顯變化（CPU，內存，I/O），但request的響應時間很長。

緣由：觀察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工具的緣由，仍是服務器的緣由。