redis rehash造成的内存增长

一、故障问题

运维的同学反应：某个业务的redis使用总量内存增长了大约20g，但是业务访问量却没有显著增长。

仔细排查过，一直没有没有查到原因。这部分突增的内存开销是由什么造成的，消耗在哪里？

内存增长如下图：

image.png

日志中没有异常信息。但是观测到，cow耗费内存同时增长。

实例redis_cluster_feed_d2_0_39200异常日志：

image.png

二、问题排查过程

为了排查问题方便，选取redis_cluster_feed_d2_0_39200实例作为排查对象。

1. 排查这部分开销是内核系统行为，还是redis主动行为。这部分主要通过used_memory来确定。

    监控显示同时段used_memory增长了2g，确定是redis的主动行为。

image.png

2. 排查这部分开销是用在kv上，还是其他开销上。

    观测到前后时段落磁盘rdb大小几乎没变化，而且dba之前也做过rdb key分析，都显示key的数量、类型、大小都无显著变化。

    说明没有bigkey，也没有大量写入。

    建议dba将前后两个时间段的rdb重新加载，以确认是否是kv存储造成的其他开销。交给dba确认。（这个做了，就可以直接确认rehash问题，不需要继续后面的排查）。

3. 跟2同步排查这部分开销是否是业务访问造成。这部分主要通过instantaneous_input_kbps，qps, bigkey来查看。

    大流量和bigkey都容易造成内存爆涨（但一般爆涨之后，这部分内存都会及时归还，其实不会出现只归还一部分内存的情况）。

    监控显示同时段qps大约600左右，instantaneous_input_kbps大约30上下，非常小。且dba反应，这是一个写少读多的业务。排除业务访问造成的影响。

image.png
image.png

4. 经过以上排查，基本可以确认这是由于redis为了维护自己的数据库主动发起的。

     比如常见的清理过期键，清理超时客户端，给slave发送ping，rehash等等。其中rehash非常容易造成内存爆涨（网上文章很多）。
   

   5. 排查是否由rehash造成该问题， 网上测试显示：

      (a) 当num(keys)=215=32768，从下面可以看出到key的个数为32769时，内存涨了一些，但是还不明显。

      
      image.png
      

      (b) 当num(keys)=220=1048576，从下面可以看出到key的个数为1048577时，内存涨了32M。

      因为rehash会扩容，所以新的哈希表中的槽位变为了221 * 2（因为每个key都设置了过期时间，expires表），指针为8个字节，221 ️ 2 ️ 8 = 225 = 32MB

      
      image.png
      

      (c) 当num(keys)=226=67108864，从下面可以看出到key的个数为67108865时，内存涨了2GB。
      因为rehash会扩容，所以新的哈希表中的槽位变为了227 * 2（因为每个key都设置了过期时间，expires表），指针为8个字节，227 ️ 2 ️ 8 = 231 = 2GB

      
      image.png
      Redis过期键存储：

      命令：expire key seconds
      存储时未过期：往expire库中添加/或者替换一条expires[key]:timeout数据
      此时数据库中存在两条关于这条key的信息：
      dict------dict[key]:value
      expires--expires[key]:timeout

      所以是有两个字典的，也就是说没有过期键时，当key到达 134217730=67108864*2时，由于rehash的原因会增长2g。

      当时我们线上实例的num(keys)=134372150略微大于134217730，也是符合这个情况的。整个增长过程如下图：

      
      image.png

三、结论

1. 内存增长原因：当key到达 134217730=67108864*2时，由于rehash的原因会增长2g。

2. 归还1g原因：rehash完成后，会释放ht[0]。

3. cow增长原因：rehash过程会更改数据数据指针。造成大部分数据虽未被访问，但是却发生改变，进而导致大范围的缺页异常。