如何消除处于time

检查net.ipv4.tcp_tw当前值，将当前的值更改为1分钟：

[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw

net.ipv4.tcp_tw_reuse = 0

net.ipv4.tcp_tw_recycle = 0

[root@aaa1 ~]#

vi /etc/sysctl

增加或修改net.ipv4.tcp_tw值：

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

使内核参数生效：

[root@aaa1 ~]# sysctl -p

[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收

用netstat再观察正常

这里解决问题的关键是如何能够重复利用time_wait的值，我们可以设置时检查一下time和wait的值

#sysctl -a | grep time | grep wait

net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

这样的现象实际是正常的，有时和访问量大有关，设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收。

net.ipv4.tcp_syncookies=1 打开TIME-WAIT套接字重用功能，对于存在大量连接的Web服务器非常有效。

net.ipv4.tcp_tw_recyle=1

net.ipv4.tcp_tw_reuse=1 减少处于FIN-WAIT-2连接状态的时间，使系统可以处理更多的连接。

net.ipv4.tcp_fin_timeout=30 减少TCP KeepAlive连接侦测的时间，使系统可以处理更多的连接。

net.ipv4.tcp_keepalive_time=1800 增加TCP SYN队列长度，使系统可以处理更多的并发连接。

net.ipv4.tcp_max_syn_backlog=8192

net.ipv4.tcp_syncookies = 1

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1

#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout = 30

#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1200

#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。

net.ipv4.ip_local_port_range = 102465000

#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。

net.ipv4.tcp_max_tw_buckets = 5000

#表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，

#TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。

#对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，

#但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死

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 工具的原因，还是服务器的原因。

---