前一段时间,开发环境反馈,Redis服务器访问非常慢,每个请求要数秒时间,重启之后2~3天又会这样。 我查看了一下Linux的性能,没有什么问题。通过 # redis-cli --latency 发现访问Redis确实很慢,执行info要几秒时间。里面有个参数已连接的客户端几万个,通过 Redis>client list 查看到很多client的age都很大,一直没有释放。于是怀疑是不是和这个有关,因为版本是2.8.6,无法通过client一次性kill掉所有的连接,只能写一个程序,一个一个地kill掉( CLIENT KILL addr:port)。但问题依然存在。 于是进一步查看配置文件,发现SHNAPSHOT是默认打开状态, save 900 1 save 300 10 save 60 10000 因为我们缓存是用于Session保存,不推荐快照保存,特别是在Redis是VM机器上,对整体的性能影响会很大。于是参考我们的手册注释:################################ 快照 ################################# # 保存数据到磁盘,格式如下: # save <seconds> <changes> # 指出在多长时间内,有多少次更新操作,就将数据同步到数据文件rdb。 # 相当于条件触发抓取快照,这个可以多个条件配合 # 比如默认配置文件中的设置,就设置了三个条件 # save 900 1 900秒内至少有1个key被改变 # save 300 10 300秒内至少有300个key被改变 # save 60 10000 60秒内至少有10000个key被改变 # Session缓存服务器不使用快照,都注释 # save 900 1 # save 300 10 # save 60 10000 重启Redis之后,观察了一个月时间,再没有反馈到性能问题了。 另外在没有使用客户端的PUB/SUB的情况下,建议参考下面的参数,设置客户端的连接超时,在300毫秒后,如果不用,服务端会自动关闭连接,释放资源。默认是关闭的。 # 设置客户端连接时的超时时间,单位为秒。当客户端在这段时间内没有发出任何指令,那么关闭该连接 # 0是关闭此设置 # 推荐5分钟。 timeout 300 # TCP keepalive # 在Linux上,指定值(秒)用于发送ACKs的时间。注意关闭连接需要双倍的时间。默认为0。 # 推荐60。 tcp-keepalive 60 注: Redis 2.8.12已经可以通过client类型,一次性kill到所有相关的连接。 |
|