在一个阳光明媚的下午,突然生产环境有一个缓存实例发出内存使用率超过90%的告警,然后立刻和小伙伴们一起看是什么情况。
现象是这样的,集群里的一个实例的内存使用率超过了90%,而这个实例的从节点,内存使用率却很低。而且其他分片的内存使用率都很低,只有这个分片高。见下图cachecloud实例状态图。
首先想到的肯定是大key导致的集群倾斜了,于是就先把这个分片的数据dump出来,然后使用rdbtools工具分析下dump文件,把大key找出来,再联系业务人员。
在做rdb分析的同时,也考虑到,会不会是有人偷偷连接了实例,然后使用了monitor忘记关掉,于是另外登录到该实例所在的服务器并连接实例后使用client list命令查看客户端的连接,看是否有带monitor相关命令的。发现并没有。
~]$ redis-cli -p 9999 client list | grep monitor
~]$
另一方面使用连接实例使用bgsave命令生成dump数据文件的同事也发现,生成的数据文件的大小只有130多M,分析虽然也分析出来了一个大key,但是大小也只有130多M,是一个拥有360多万个元素的List。
但是这应该完全不足以造成9个G的内存使用量。我还以为是bgsave命令没正常执行?我又重新执行了一次bgsave命令,查看执行时间和dump数据确认确实是130多M。使用info命令查看实例的信息,也看不出问题。</
Redis实例内存暴涨之谜:大key与输出缓冲区

当一个Redis实例的内存使用率超过90%,而其从节点和其他分片内存正常时,排查发现是由于客户端频繁全量获取大List导致输出缓冲区积压。通过分析dump文件、检查clientlist命令,找出占用大量内存的客户端连接,并通过kill命令关闭相关连接,从而解决了内存问题。
最低0.47元/天 解锁文章
1217





