记一次Redis内存过大的问题排查处理过程

一、背景

  近期协助同事排查处理了一个redis内存占用过大的问题，服务器内存为512G，我救火时redis已使用了300G左右的内存，且还有持续增加的趋势。虽然经过多种方式排查最终定位了问题，不过也走了一些弯路，现将问题排查经过记录分享一下，希望能帮助到查阅到此文的朋友。

二、过程

（一）了解情况

  接到这个问题排查任务，首先和相关同事了解了基本情况：该redis是用于记录过程数据，在最终收到结果数据时会取出过程数据进行计算并最终释放掉所有的过程数据，同时过程数据也有设置过期时间，如果最终没有收到结果数据，内存也会得到释放。

（二）分析处理过程

​  按照同事介绍的程序设计，既然redis数据在逻辑上不应该存在这种情况，首先决定通过云桌面环境连上redis查看一下存储的数据情况。我使用的Redis工具是Another Redis Desktop Manager，通过该GUI工具连接上后发现该Redis下面有10个目录（此处的10个目录，为后续排查走弯路埋下了伏笔），线上环境的Key数量大概在500W+，有过期时间的key仅有200w不到，遂怀疑是否因为程序bug导致部分数据永久驻留内存导致内存使用过大。

1.统计永不过期的key数量

  因为是生产环境，为了不阻塞服务器，故采用编写脚本的方式，使用scan命令扫描各个目录下永久key的情况，和同事沟通各个目录缓存数据的作用。经过沟通发现有两个目录是由于程序历史版本bug所致，数据已经不会再写入，可以放心清理；有一个有最新数据的目录，数据全部是永久，是由于程序配置不当所致；

2.清理无效key

  经过上述沟通确认，遂再次编写脚本，采用scan扫描定位到可以删除的key，采用unlink删除了约200W的key，内存释放了10G左右，来到了290G左右。清理了40%的key，内存并未得到大量释放，还需进一步排查。

3.memory usage逐一统计各目录内存占用

  仍然是编写脚本，采用scan + memory usage [key] 的方式对10个目录的内存占用进行统计，累加起来发现和used memory相差甚远。

4.memory stats分析内存情况

  使用memory stats命令获取redis的内存情况，发现每个key平均内存占用达到了惊人的100K+，和上述memory usage统计的结果相去甚远。

5.使用rdbtools分析内存占用情况

  通过memory stats命令获取到平均每个key的内存占用达到了100K，怀疑memory usage命令不精确，准备使用rdbtools工具再次分析下内存占用情况。咨询运维人员redis的rdb文件大小情况，得知达到了100G+，直接使用rdbtools的rdb命令分析存在一定的困难，决定使用rdbtools提供的redis-memory-for-key命令对部分key进行抽样，发现和memory usage的结果偏差不大。

6.排查缓冲区情况

  对key的情况，使用了memory usage，也采用了redis-memory-for-key命令分析；对于redis缓冲区，也使用client list命令排查了各个连接的omem值情况正常，遂怀疑是否有key被漏扫了。

7.再次使用memory usage排查大key

  修改前述脚本，不再按目录扫描key，而是全量扫描，发现有一个目录仅有两个key，但内存占用达到了惊人的212G！

8.处理

  定位到罪魁祸首，处理就容易多了，对这两个key采用unlink进行非阻塞删除，观察内存使用，下降到了6G，问题得到解决。

三、总结

  Another Redis Desktop Manager是采用的按key比例增量加载数据方式，如果存在少量目录的key占用大量内存的情况，不一定能通过GUI工具发现问题。总结此次问题排查过程，RedisGUI工具没有将所有的目录展示出来，导致此次故障排查走了不少弯路，除此之外也还有些过程值得反思和改进：

• redis内存占用排查，首选应该是redis-cli --bigkeys命令，该命令可以在生产环境使用，不会阻塞redis主进程；如果一开始采用了此命令，也可以少走弯路；
• 线上环境，redis扫描一定要使用scan方式，禁用keys命令；对于大key或大量key，删除使用unlink，禁用delete。