小编点评

## Redis内存占用分析报告 **日期:** 2023年10月27日 **时间:** 下午3:00 **问题:** 3个Redis Sentinel集群节点内存占用都很高，达到17GB的内存占用量。 **分析工具:** * Redis官网工具 * 第三方工具 (例如: redis data reveal) **结论:** * 单个Value或单个集合中的元素应该保证不超过10KB。 * 使用Redis过程中，单个Value或者单个集合中的元素应该保证不超过10KB。 **问题原因:** 由于Redis的Key存储在内存中，单个Value或单个集合中的元素应该保持在10KB以下才能被有效存储。如果超过了这个限制，就会导致内存占用问题。 **解决方案:** 1. 确保使用Redis的最佳实践体验。 2. 对Key大小进行监控，并确保其符合10KB的限制。 3. 优化Redis集群的配置，例如设置缓存数据量等。

正文

问题背景

在一个风和日丽的下午，公司某项目现场运维同学反馈，生产环境3个Redis的Sentinel集群节点内存占用都很高，达到了17GB的内存占用量。

稍加思索，应该是某些Key的Value数据体量过大，占用了过多的内存空间，我们在使用Redis的过程中，单个Value或者单个集合中的元素应该保证不超过10KB，已获取最佳的实践体验。

工具推荐

网上搜索了一番，关于分析大Key的工具还挺多，分为Redis官网工具和第三方工具。

经过一番比对，不同的工具都体验了一下，这里跳过工具之间的对比过程，直接给结论：redis data reveal。

大家可以在releases中下载打包成的应用程序，这里也给个国内加速下载地址：蓝奏云。

因为线上已经开启了Redis的RDB和AOF持久化策略，直接把RDB文件拉到本地。

如果没有开启RDB可以使用bgsave命令导出

执行RDB文件分析命令：

chmod +x rdr-linux
./rdr-linux show -p 8099 dump.rdb

分析完成后会在设置的端口打开web服务，我们的RDB文件有4GB，分析耗时大概5分钟，分析过程日志如下：

start parsing...
parse dump.rdb  done
parsing finished, please access http://{$IP}:8099

打开分析报告页面，查看到的queue:sdk:audit:log占用了17GB内存，经分析后发现是由于下游消费服务未部署导致队列数据积压所致：

通过Redis集群的Slave节点，再次查看对应的key大小（字节数）：

127.0.0.1:9532> memory usage queue:sdk:audit:log
(integer) 18124761989