这是一个创建于 3616 天前的主题，其中的信息可能已经有所发展或是发生改变。
Python 操作 redis 时，由于 redis 实例线程安全，所以我使用了两种方式:
(1).直接做全局变量，如下：
R = redis.Redis() # 导入到多个需要使用 redis 的模块中，直接使用，如： R.get('name') (2).连接池，如下：
class mRedis(object): def __init__(self, db=0): self.db = db self.redis_pool = redis.ConnectionPool(host=settings.redis_svr_addr, port=settings.redis_svr_addr_port, db=self.db, password=settings.redis_svr_pass) def getR(self): return redis.Redis(connection_pool=self.redis_pool) # 实例化直接使用 myredis = mRedis(db=0).getR() 但是在使用过程中，产生了大量 CLOSE_WAIT.,一大屏幕，如下：
tcp 1 0 127.0.0.1:62286 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15153 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14972 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15134 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15030 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:62486 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15097 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:4912 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14517 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15155 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:59812 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15031 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15121 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14812 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:59806 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14813 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:14928 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:63476 127.0.0.1:6379 CLOSE_WAIT tcp 1 0 127.0.0.1:15048 127.0.0.1:6379 CLOSE_WAIT 其中 redis.conf 设置 timeout 200
而且时常会出现 redis 连接超时的问题，导致 tornado 一直阻塞请求，看了下带宽，负载,CPU,内存都比较正常,暂时找不到原因，不知道是 redis 使用方面出了什么问题？求指点！！:-D
22 条回复 2018-12-25 16:03:58 +08:00
 | 1 BeginMan OP 查了慢查询日志，发现 6379> SLOWLOG get 1) 1) (integer) 0 2) (integer) 1441609701 3) (integer) 151130 4) 1) "SAVE" |
 | 2 sujin190 2015-11-19 14:56:23 +08:00 每次生成连接池？那不是和每次打开连接一样了，还不关闭。。 |
 | 4 HunterPan 2015-11-19 15:06:32 +08:00 close wait 从大道理上讲是客户端关闭了，但服务器段没再握手。 |
 | 5 ufo22940268 2015-11-19 15:07:27 +08:00 前几天，因为我的 redis 版本不够高， ucloud 把我的 vps 限流量了。 LZ 看看这几天 redis 是不是出了什么高危漏洞 |
| 7 HunterPan 2015-11-19 15:09:25 +08:00 上述表述有误：应该是主动关闭方，发起关闭，而被动方没有发送第二次握手。 |
| 8 BeginMan OP @ufo22940268 谢谢，我的是版本是 redis 3.0.2 ，应该比较稳定，偶数不是稳定版本么。刚查了下好像没漏洞提示。 |
 | 9 ipconfiger 2015-11-19 15:14:17 +08:00 pip install tornado-redis |
| 10 BeginMan OP @ipconfiger 你好，这个已经在项目二用上了。 |
 | 11 pubby 2015-11-19 15:29:50 +08:00 为啥 Recv-Q 里面还有数据 1 |
| 12 BeginMan OP 全部改成线程池的方式后，观察了 半个多小时， CLOSE_WAIT 少了一大半。 |
 | 13 sleeperqp 2015-11-19 16:44:05 +08:00 应该是客服端发送 close 请求 服务器端没有关闭 |
 | 14 BOYPT 2015-11-19 16:50:03 +08:00 CLOSE_WAIT 的意思就是已经关闭了，再多都没关系。 |
 | 15 ryd994 2015-11-19 17:23:27 +08:00  1 |
 | 16 e1eph4nt 2015-11-19 18:06:07 +08:00 看起来是 server 端关闭的， client 端还没读到这个 fin ，所以 recv-q 里面还有一个 segment |
| 17 pubby 2015-11-19 18:34:14 +08:00 @e1eph4nt server 端关闭不会有 CLOSE_WAIT 的 https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/TCP_CLOSE.svg/2000px-TCP_CLOSE.svg.png 应该是收到了 FIN ，回了 ACK ，自己没发 FIN |
 | 18 esplendo 2015-11-19 19:41:32 +08:00 @ufo22940268 @BeginMan 是这样的，当时我们监测发现您的云主机未做针对 Redis 安全漏洞的措施，此台云主机有很大可能已经被入侵，对此我们先将此台云主机带宽进行限流。也麻烦尽快完善安全措施。 注：限流带宽值仍高于您的购买带宽，主要防止主机被攻破后出现异常流量及攻击行为。 |
| 19 e1eph4nt 2015-11-19 20:28:32 +0:00 @pubby 确实 kernel 应该已经回复了 ack ，我说的 client 指的是 user 态，不是很确定，只是试图解释为什么 recv-q 里面还有 1 |
 | 22 zhu123456 2018-12-25 16:03:58 +08:00 楼主 您好，请问您当时这个问题最后是怎么解决的？十分感谢 |
Select Language