Redis连接错误的情况总结分析

前言

最近由于流量增大,redis 出现了一连串错误,比如:

  • LOADING Redis is loading the dataset in memory
  • use of closed network connection
  • connection pool exhausted
  • connection refuse by peer

一个个来分析。

LOADING Redis is loading the dataset in memory

这里至少有2种可能

  • 可用内存太小,修改 redis.conf 中的 maxmemory 即可解决
  • redis 在启动时正在加载 dump.rdb 文件,由于加载比较慢导致 redis 在启动时不可用

我遇到的就是第2种情况,AWS在自动扩容的时候,每个新产生的 EC2 实例都报错,原因就是 redis 在启动时发现有个 dump.rdb,然后就去加载它,导致服务器里的服务都报错,然后就退出了,并且 redis 加载这个要好久(不知道为什么),supervisord 自动重启了新的服务后依然报错。

后来把镜像中的 dump.rdb 文件删了,服务才能正常启动。

dump.rdb 文件产生的原因可能是之前 redis 出现了某种错误,然后在制作镜像时也做进去了,导致新生成的实例个个都报错。

这次吸取了教训,下次制作镜像之前都要先 stop 掉 redis 然后删掉 dump.rdb 。

其他3种错误

一开始也是各种找资料,然后各种改配置,导致这3种错误都先后出现。

一开始我认为是 golang 代码没有正确处理 redis 连接异常的情况,于是各种升级 redigo,改 golang 中的 timeout 、max_active、wait 等的配置,发现都没有用。

这样来来回回折腾了大概一周,终于从 pool.Active 和 pool.MaxActive 中发现了猫腻。

因为我 MaxActive 设置的是 10000,于是我开了 10000 个 go runtine 去测试它,发现当前连接数 pool.Active 老是才 4000 左右,然后就各种报错。

那段时间也是脑子短路了,老是认为 redigo 没有正确处理 redis 的连接才导致 pool.Active 不能上到最大。老是想着改 redigo 的代码……

后来实在没办法,想着去改一改 ulimit,旧的是 500000,改到 990000,发现还是报连接错误,pool.Active 还是上不去,我想这不可能啊,这才想到会不会是 redis 本身有最大连接数的配置。上网一查,果然,redis-server 有一个 maxclients 的配置……默认是 4000 多,改到 10000 后,整个世界都清静了……

其实也不能怪我,因为 redigo 也有个 max_active 参数,鬼知道 redis-server 还要设置呢 [笑哭]?

Redis 用于高并发服务的配置

Redis 客户端(即 golang 代码)

Wait: true 如果连接池满了,就等待, Redis 处理很快的,等个几微秒用户也感觉不出来什么
IdleTimeout: 5s 一个业务逻辑5s都处理不完,那你应该优化你的代码了。如果设置为0,万一这个连接失踪了服务端就收回不了了,会产生僵尸连接的。

MaxActive: 10000 相当于这个服务器能处理每秒 10000 并发了。

Redis 服务器(即 redis-server)

maxclients 要设置得比 MaxActive 大

附加题:一台服务器的最大文件数怎么算?

linux kernel - Need to “calculate” optimum ulimit and fs.file-max values according to my own server needs - Stack Overflow

this ends up being about 100 for every 1MB of ram.

例,如果是 4G 内存,那么打开文件数最大可以设置为:4 * 1024 * 100 = 409600

总结

相关推荐