php服务器 与redis交互大量CLOSE_WAIT分析

最近发现有一台访问量很小（大概1000次/天）的服务器，在与redis交互的过程中，出现了大量的CLOSE_WAIT网络状态，导致fd资源被打满。初看很反直觉，访问量小而占用资源特别多，最终通过分析tcp协议，以及分析php-fpm模型，最终找到并解决了问题。

查询linux中tcp情况的命令：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 

 

大量close_wait状态

1.CLOSE_WAIT原理

在断开tcp连接时，会有一个4次挥手的过程。主动断开的一方会发起一个FIN包，接收方收到后会返回一个ACK包告知发起方我知道你要断开了，此时接收方状态变更为CLOSE_WAIT并处理收尾工作。正常的情况下，接收方在处理完收尾工作后，会给发起断开的一方发送一个FIN包，然后在收到断开发起方返回的ACK包以后，整个4次挥手的过程也就结束了。
但是不正常的情况下，接收方不发送FIN包，导致其状态一直是CLOSE_WAIT状态，如果每一个连接都这样，就会占用大量的系统资源，导致无法对外提供服务。

4次挥手

2.访问量这么小的php服务器，与redis 交互为什么会出现CLOSE_WAIT状态

php与redis交互分析

在php中，并没有redis连接池的概念，所以为了避免不断地连接、断开与redis的连接，我们在php中一般采用长连接的形式与redis进行交互。

这种形式创建的连接的生命周期和php-fpm进程的生命周期是一致的，所以每次有新的请求过来，都会复用php-fpm最初创建的redis连接，这样就节省了不断的连接、断开连接redis产生的网络开销。

php-fpm的生命周期

php-fpm 有一个配置pm.max_requests表示，php-fpm进程经过pm.max_requests个请求后会销毁并生新生成一个子进程。这也就代表着1个fpm了进程需要经历max_requests个请求后才会销毁

pm.max_requests = 50240

定位到问题

从php与redis的交互分析，可以得出：一个reids长连接的生命周期和php-fpm子进程是一致的。
而php-fpm的生命周期为经历pm.max_requests 个请求，而我们服务器的配置为50240。
同时，出现问题的服务器访问量特别小（1000次/天），也就是说一个php-fpm的生命周期至少为50天（50240/1000=50,应该更多的，因为不止一个进程），那么redis连接的生命周期也至少为50天。
在这50天中，redis会给php服务器发起断开请求，php服务器会返回一个ACK，然后变更状态为CLOSE_WAIT，但是php服务器不会再发送一个FIN包给redis，因为它的生命周期没有结束。所以最终会产生大量的CLOSE_WAIT。

3.为什么访问量大反而不会出现CLOSE_WAIT

访问量大，意味着php-fpm进程的max_requests很容易触达，php-fpm的生命周期会很短，还达不到redis服务器的超时断开的触发时机。

4.解决方案

改用短连接~

参考：

http://www.gosanye.com/post/10160.html

参考：http://t.zoukankan.com/xinfang520-p-8961129.html