linux - 为何redis的TIME_WAIT值如此之高

Question

我用的是redis的pecl客户端，在代码里使用的是connect函数，并且每次请求都手动关闭了连接。但最近iammutex的一个回答提醒了我关注下系统的连接数，于是我在晚上访问量比较小的时候看到如下让我吃惊的结果

netstat -na | grep 6379 | grep TIME_WAIT | wc -l
446

在redis端口上居然有446个TIME_WAIT。我不知道这种情况是否算正常呢？如果不正常，应该优化哪些参数？

Answer 1

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

原理：redis的客户端close一个链接以后，这个链接就会进入TIME_WAIT状态，而TIME_WAIT状态的链接会在Max Segment Lifetime内都没有活跃包的情况下关掉。Linux这个默认值貌似很长，具体的数值还真不知道，似乎是分钟级的。。。
悲剧的是，一条TCP链接是死是活由源IP和端口，目标IP和端口四个变量决定。那客户端和服务器的这四个值都是固定的，所以每次建立新链接的同时，处在TIME_WAIT的链接也被告知，你还不能死。
所以执行上述命令，让tw状态的链接可以reuse

补充：/proc/sys/net/ipv4/tcp_tw_recycle 如果设成1的话，就是快速回收tw链接，应该也能解决问题

Answer 2

几百应该不算高，手动close连接是说向Redis发送QUIT命令吗？如果是的话，由于发送了QUIT命令后，Redis会主动断开连接，TCP中主动断开的一方确实会保持TIME_WAIT一段时间。其实几百个不是什么大问题，TW状态也不会占用太多资源。
对于防止TW过多，@gaosboy 说到了一点reuse，一般可以设置下面几个TCP参数来进行TCP连接的优化。

vim /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
/sbin/sysctl -p //使之生效

不过我个人觉得SF慢的原因真的需要细查一下。网络连接上确实没有任何问题的。而目前打开页面至于是2s以上，平均是3s多。如果优化优化，速度提升个十倍以上应该不是问题。

Answer 3

请点击此问题进行查看http://sfau.lt/eHhgZN，可以解决你的问题了。

UP：原因一样：

connect之后没主动关闭

详细参见文档说明

connect, open
Description
Connects to a Redis instance.

Parameters
host: string. can be a host, or the path to a unix domain socket
port: int, optional
timeout: float, value in seconds (optional, default is 0 meaning unlimited)

Answer 4

请不要手动修改收回连接的超时时间, 操作系统设计这个超时是因为 客户端与服务器之间的传有可能有延时, 还有就是端口重用的问题. 所以最好用单例实现一个或多个连接或使用连接池.