Redis内存占用远超键值总大小求助：clients.normal占用大量内存致服务崩溃

从你给出的memory stats输出能明确看到，clients.normal占用了约11.5GB的内存，这是导致Redis进程内存远超键总大小的核心原因——正常情况下，普通客户端连接的内存占用不会达到这个量级，下面给你一步步的排查和解决方向：

1. 定位异常客户端连接 #

首先用CLIENT LIST命令获取所有客户端连接的详细信息，重点关注这几个字段：

• omem：该连接的输出缓冲区占用内存，数值异常高的就是重点排查对象
• idle：连接的空闲时间，长时间空闲却没被回收的连接可能存在泄漏
• cmd：该连接最近执行的命令，能帮你判断是否是大结果命令导致的缓冲区堆积

你可以用这些命令快速筛选关键信息：

# 筛选输出缓冲区大于100MB的连接
redis-cli client list | grep -E "omem=[0-9]{8,}"
# 精简显示连接ID、空闲时间、输出缓冲区大小
redis-cli client list | awk '{print $1, $3, $4}'

2. 分析输出缓冲区暴涨的根源 #

如果发现某个/某些连接的omem数值极高，通常是以下两种情况：

• 客户端未及时读取响应数据：比如客户端执行了KEYS *、HGETALL这类一次性返回超大结果的命令，但客户端进程卡住、网络中断，或者读取速度远跟不上Redis的返回速度，导致输出缓冲区持续堆积数据。
• 订阅/发布模式消息堆积：如果使用了Redis的Pub/Sub功能，当订阅者消费速度远慢于生产者的发布速度时，未被消费的消息会在Redis的客户端输出缓冲区中堆积。

另外，检查你的Redis配置文件redis.conf中的client-output-buffer-limit参数，默认普通客户端的限制是0 0 0（无任何限制），这会让Redis无限制地为客户端缓冲区分配内存，最终导致内存耗尽。

3. 排查连接泄漏问题 #

结合你给出的keys.count（仅8579个键），正常来说不会需要这么多高内存连接。检查是否存在客户端连接泄漏：比如应用程序每次请求Redis后没有正确关闭连接，导致连接不断积累，每个连接都可能持有未读取的响应数据。

可以用INFO clients命令快速查看客户端整体状态：

redis-cli info clients

重点关注connected_clients（当前连接数）、client_longest_output_list（最长输出列表长度）、client_biggest_input_buf（最大输入缓冲区大小）这几个指标。

4. 临时缓解与长期修复 #

临时处理 #

如果找到明确的异常连接，直接用CLIENT KILL <ip:port>命令杀掉对应的连接，快速释放内存：

# 示例：杀掉192.168.1.100:54321的连接
redis-cli client kill 192.168.1.100:54321

长期修复 #

• 配置客户端缓冲区限制：修改redis.conf，给普通客户端设置合理的缓冲区阈值，比如：

  client-output-buffer-limit normal 256mb 64mb 60
  

  意思是：当普通客户端的输出缓冲区超过256MB，或者60秒内持续超过64MB时，Redis会主动关闭该连接。
• 优化客户端代码：
  • 避免使用KEYS *、HGETALL这类返回超大结果的命令，改用SCAN、HSCAN等分批遍历的命令。
  • 确保客户端在处理完Redis响应后及时读取数据，并正确关闭连接（比如使用连接池管理连接）。
  • 如果使用Pub/Sub，保证订阅者的消费速度能匹配生产者的发布速度，必要时增加消费端的并发能力。
• 开启慢查询日志：在redis.conf中开启慢查询日志，排查是否有耗时或返回超大结果的命令被频繁执行：

  slowlog-log-slower-than 10000 # 记录执行时间超过10ms的命令
  slowlog-max-len 1000 # 保存最近1000条慢查询记录
  

5. 后续监控 #

配置定期监控，采集MEMORY STATS中的clients.normal、INFO clients中的相关指标，设置告警阈值，当客户端内存占用超过预警值时及时通知，避免再次出现内存耗尽导致服务崩溃的情况。

内容的提问来源于stack exchange，提问作者lucaswxp