先看一副TCP连接关闭的状态图（  ）：

被动关闭一方才会出现 CLOSE_WAIT 状态，由于被动关闭方未调用 close 关闭socket导致，问题肯定是由服务器代码引起。

检测到对端socket关闭然后关闭本端socket是由 node.js 自行完成的，最大的可能是没有机会执行 close 。

我们的应用客户端与服务器有一个tls长连接，当连接断开时客户端会等待3-10秒后尝试重连服务器，如果服务器出现卡顿会导致客户端频繁重连，

如果服务器来不及关闭这些连接，则会出现 CLOSE_WAIT 状态的连接，占用大量文件描述符，减少 CLOSE_WAIT 超时时间能够在一定程度上缓解这个问题，

但是对于我们这种长连接的环境，大量CLOSE_WAIT是问题的表象，而非根源。

参考：《》

伴随着 CLOSE_WAIT 出现的状况是 node.js 进程内存及CPU占用超高，单node.js进程内存占用达到 1.5G，CPU占用 90% 以上，此时应该会导致 node.js 响应慢， 来不及关闭连上来的socket。

所以解决问题的关键就是：找出什么原因导致 node.js 内存及CPU 100%占用。

想到的可能是redis负载过高引起，从运维监控图上可以看出一些蹊跷，node.js出问题时redis的连接数也同样彪升，而出问题的机器上刚好就是跑redis的机器， 另一台服务器一直相安无事，没有跑redis。

在晚上两点的时候服务出现问题，同样的现象，特别留意了一下redis的统计，请求速度很低，只有1200，平时都是5000。偶然在进程列表中发现了 redis-rdb-bgsave 的身影， 不断地执行ps看进程列表，发现 redis-rdb-bgsave 进程不断地出现，查看redis的持久化配置如下：

save 900 1save 300 10save 60 10000

我们的系统有大量的redis，1分钟肯定过万，这样redis持久化变是常态了，而且由于用的是机械硬盘，持久化肯定会引起系统卡顿，先将它调整为15分钟最多持久化一次：

config set save "900 1"

重启程序释放资源后系统开始正常响应，但是10多分钟后系统再次无响应，才想起一则经验教训：

跑redis的机器至少要预留和redis占用内存同样大小的空闲内存空间，redis RDB持久化进行fork时最坏会占用双倍内存，内存不足就会动用交换分区，系统性能急剧下降。

于是，立即改配置将redis所在机器上的node.js cluster进程数调小，腾出大把内存，总算没有再出现问题，今晚终于可以入眠。

• 我们的node.js进程为什么常常会占用很多内存？
• netstat中看到CLOSE_WAIT状态的连接输入缓冲往往有数据，而ESTABLISHED状态的连接读写缓冲区往往为空，为什么？
• node.js卡顿时forever杀不死反而启动了新实例帮倒忙，pm2就一定能够解决吗？
• redis持久化引起服务挂掉，已经是在第二个项目中遇到了，终极解决方案是什么？