记一次Redis数据库配置导致的连接数泄露的问题

本文记录了一次由于Redis默认配置导致的连接数泄露问题,通过监控和分析,发现连接数异常增长,最终定位为Redis未修改默认配置。修复措施包括调整Redis配置,确保网络稳定和客户端正确关闭连接,问题得以解决。
摘要由CSDN通过智能技术生成

问题背景

去年圣诞节当天,突然收到一个我经手过的项目的告警邮件,错误消息显示“Redis::CommandError: ERR max number of clients reached”
Redis 连接数告警

什么情况?难道这个项目翻车了?第一反应是这台服务器运行着自建的 Redis 数据库,但是客户端只有同个内网的一个 Ruby on Rails 的应用,怎么会有连接数爆掉的可能?

理论连接数计算

老衲掐指一算:

  1. sidekiq 客户端所需连接数: 对面 Rails 应用有 10 个 Unicorn 工作进程,每个unicorn进程初始化一个 sidekiq 客户端,一个 sidekiq 客户端默认连接池大小是 5,而且是懒惰策略,按需连接的,最大值是 10 x 5 = 50;
  2. 显式 Redis 连接: 程序代码里有一个 $redis 全局变量,初始化了一个 redis 连接,10个工作进程,也就是 10 个连接;
  3. sidekiq 服务端所需连接数: sidekiq server 端 concurrency 配置是 10,那么按照官方文档,另有加上 2 个连接,也就是12个连接;
  4. Rails cache 所需连接数: 按照
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值