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
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 +08:00
@pubby 确实 kernel 应该已经回复了 ack ,我说的 client 指的是 user 态,不是很确定,只是试图解释为什么 recv-q 里面还有 1
|
22
zhu123456 2018-12-25 16:03:58 +08:00
楼主 您好,请问您当时这个问题最后是怎么解决的?十分感谢
|