相信很多运维工程师遇到过这样一个情形: 用户反馈网站访问巨慢, 网络延迟等问题, 然后就迫切地登录服务器,终端输入命令"netstat -anp | grep TIME_WAIT | wc -l " 查看一下, 接着发现有几百几千甚至几万个TIME_WAIT 连接数. 顿时慌了~
通过 "netstat -anp | grep TIME_WAIT | wc -l" 命令查看数量,发现TIME_WAIT的连接数量很多! 可能是因为服务器主动关闭连接导致TIME_WAIT产生了很多. 发现系统存在大量TIME_WAIT状态的连接, 可以通过调整系统内核参数来解决: 打开 sysctl.conf 文件，修改以下几个参数： [root@web01 ~]# vim /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_fin_timeout = 30 [root@web01 ~]# sysctl -p 接着被告知: 开启tw_recylce和tw_reuse功能, 一定需要timestamps的支持，而且这些配置一般不建议开启，但是对解决TIME_WAIT很多的问题，有很好的用处。 果然, 经过如上配置后, 过了几分钟，再查看TIME_WAIT的数量快速下降了不少，并且后面也没发现哪个用户说有问题了. 做到这里, 相信大多数运维人员想当然地以 为问题已经解决了,但是，要彻底理解并解决这个问题，可能就没这么简单，或者说，要想彻底搞清楚并解决这个问题, 还是有很长的路要走滴! 相关查看命令: [root@web01 ~]# netstat -n | awk \'/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}\' 会得到类似下面的结果,具体数字会有所不同: LAST_ACK 1 SYN_RECV 14 ESTABLISHED 79 FIN_WAIT1 28 FIN_WAIT2 3 CLOSING 5 TIME_WAIT 1669 [root@web01 ~]# sysctl -a | grep time | grep wait net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 执行命令"netstat -na"查看到的相关TCP状态解释: LISTEN: 侦听来自远方的TCP端口的连接请求; SYN-SENT: 在发送连接请求后等待匹配的连接请求; SYN-RECEIVED: 在收到和发送一个连接请求后等待对方对连接请求的确认; ESTABLISHED: 代表一个打开的连接; FIN-WAIT-1: 等待远程TCP连接中断请求, 或先前的连接中断请求的确认; FIN-WAIT-2: 从远程TCP等待连接中断请求; CLOSE-WAIT: 等待从本地用户发来的连接中断请求; CLOSING: 等待远程TCP对连接中断的确认; LAST-ACK: 等待原来的发向远程TCP的连接中断请求的确认; TIME-WAIT: 等待足够的时间以确保远程TCP接收到连接中断请求的确认; CLOSE: 没有任何连接状态;