一次 Redis 内存诡异增长的排查过程

存储 存储软件 Redis
由于哈希表的特性,Redis 中键值数量大,不会对存取造成性能影响,但是会出现本文提到的问题。控制键个数有几个建议:无用的键值设置过期时间或者定期删除。

 一、现象

实例名:r-bp1cxxxxxxxxxd04(主从)

问题:一分钟内存上涨了2G,如下图所示:

键值规模:6000万左右

内存一分钟增长2G.png

二、Redis内存分析

1. 内存组成

[[237264]]

上图中的内存统计的是Redis的info memory命令中的used_memory属性,例如:

  1. redis>infomemory#Memoryused_memory:9195978072used_memory_human:8.56Gused_memory_rss:9358786560used_memory_peak:10190212744used_memory_peak_human:9.49Gused_memory_lua:38912mem_fragmentation_ratio:1.02mem_allocator:jemalloc-3.6.0 

每个属性的详细说明

计算公式如下:

  1. used_memory = 自身内存+对象内存+缓冲内存+lua内存used_rss = used_memory + 内存碎片 

如下图所示:

2. 内存分析

(1) 自身内存:一个空的Redis占用很小,可以忽略不计

(2) kv内存:key对象 + value对象

(3) 缓冲区:客户端缓冲区(普通 + slave伪装 + pubsub)以及aof缓冲区(比较固定,一般没问题)

(4) Lua:Lua引擎所消耗的内存

3. 内存突增常见问题

(1) kv内存:bigkey、大量写入

(2) 客户端缓冲区:一般常见的有普通客户端缓冲区(例如monitor命令)或者pubsub客户端缓冲区

三、问题排查

(1) bigkey ? 经扫描未发现bigkey

(2) 键值个数增加?未发现键值有明显变化

 

(3) 客户端缓冲区

由于内存增上去后,长时间没下落,如果是因为缓冲区问题,会从info clients找到明显问题,执行后发现:

执行client中也没有明显的omem大于0的情况

  1. id=80207addr=10.xx.0.4:63920fd=46name=age=624idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  2. id=80215addr=10.xx.0.23:43489fd=36name=age=591idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  3. id=80366addr=10.xx.0.8:59785fd=18name=age=84idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=delread=0write=0type=user 
  4. id=80356addr=10.xx.0.33:32117fd=13name=age=114idle=0flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  5. id=80064addr=10.xx.59.4:53446fd=38name=age=1070idle=1070flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=NULL read=0write=0type=admin 
  6. id=80276addr=10.xx.0.23:48511fd=8name=age=387idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  7. id=80188addr=10.xx.0.33:16265fd=42name=age=681idle=3flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  8. id=80326addr=10.xx.0.32:59779fd=16name=age=209idle=0flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  9. id=80065addr=10.xx.59.4:53447fd=45name=age=1070idle=1070flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=NULL read=0write=0type=admin 
  10. id=79936addr=10.xx.0.22:10607fd=30name=age=1480idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  11. id=80174addr=10.xx.0.5:60914fd=6name=age=722idle=2flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  12. id=80300addr=10.xx.0.22:22757fd=48name=age=298idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  13. id=80037addr=10.xx.0.5:55189fd=15name=age=1143idle=2flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  14. id=80330addr=10.xx.0.8:48533fd=17name=age=199idle=10flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  15. id=79896addr=10.xx.0.30:26814fd=11name=age=1616idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  16. id=80299addr=10.xx.0.24:11227fd=44name=age=303idle=3flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  17. id=80086addr=10.xx.0.32:52526fd=40name=age=1002idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  18. id=80202addr=10.xx.0.33:16658fd=26name=age=636idle=3flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  19. id=80256addr=10.xx.0.24:60496fd=19name=age=448idle=2flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  20. id=79908addr=10.xx.0.29:18975fd=12name=age=1583idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  21. id=80365addr=10.xx.0.29:46429fd=14name=age=85idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  22. id=79869addr=10.xx.27.4:48455fd=35name=age=1700idle=1700flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=NULL read=0write=0type=admin 
  23. id=80334addr=10.xx.0.23:50012fd=39name=age=189idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  24. id=80041addr=10.xx.0.32:51107fd=33name=age=1132idle=3flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  25. id=79992addr=10.xx.0.22:12068fd=28name=age=1289idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  26. id=80251addr=10.xx.0.30:44213fd=23name=age=468idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  27. id=80006addr=10.xx.0.2:45895fd=31name=age=1242idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  28. id=80321addr=10.xx.0.30:48048fd=5name=age=224idle=3flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  29. id=80381addr=10.xx.0.8:13360fd=22name=age=24idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=delread=0write=0type=user 
  30. id=80200addr=10.xx.0.24:59183fd=24name=age=640idle=0flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  31. id=80113addr=10.xx.0.2:52492fd=21name=age=915idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  32. id=174addr=11.216.117.242:53027fd=9name=age=281390idle=0flags=S db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=replconf read=0write=0type=admin 
  33. id=79991addr=10.xx.0.4:48412fd=25name=age=1296idle=0flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  34. id=80301addr=127.0.0.1:47869fd=49name=age=291idle=261flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=strlen read=0write=0type=admin 
  35. id=80047addr=10.xx.59.4:53184fd=41name=age=1114idle=1114flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=NULL read=0write=0type=admin 
  36. id=80236addr=10.xx.0.5:62546fd=47name=age=516idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  37. id=80364addr=10.xx.0.4:18794fd=7name=age=85idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  38. id=80175addr=10.xx.0.4:62245fd=29name=age=718idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  39. id=80336addr=10.xx.0.29:45701fd=50name=age=180idle=1flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  40. id=80050addr=10.xx.59.4:53188fd=43name=age=1114idle=1114flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=NULL read=0write=0type=admin 
  41. id=79765addr=10.xx.0.2:33832fd=37name=age=2027idle=177flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=info read=0write=0type=user 
  42. id=80170addr=10.xx.0.2:57853fd=20name=age=728idle=24flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=0obl=0oll=0omem=0events=r cmd=ping read=0write=0type=user 
  43. id=80390addr=127.0.0.1:49449fd=27name=age=0idle=0flags=N db=0sub=0psub=0multi=-1qbuf=0qbuf-free=32768obl=0oll=0omem=0events=r cmd=client read=0write=0type=admin 

四、揪出元凶

常用的几招都用了,还是不行,同事@径远帮忙一起分析,怀疑是不是因为Redis的kv哈希表做了 rehash。

1. Redis的kv存储结构

如下图所示,Redis的所有kv保存在dict中,其中ht对应两个哈希表ht[0]和ht[1],平时一个空闲,一个用于存储数据,只有当需要rehash时,ht[1]才会用到。

 

2. Redis的字典rehash

为了保证哈希表的负载,当哈希表的元素个数等于哈希表槽数时候,会进行rehash扩容。扩容后h[1]的容量等于第一个大于等于ht[0].size*2的2n,例如hash表的初始化容量是4,那么下一次扩容就是8,以此类推。

3. 测试

(1) 测试方法

先批量写入到rehash阈值附近,然后在逐条去写,观察内存变化

  1. ​// 为每个键设置1天过期时间int expireTime = 60 * 60 * 24;// rehash阈值 - 50为了方便观察rehash内存变化int rehashThreshold = (int) Math.pow(2, 25) - 50;// 1.批量写入:pipeline批量写入,由于是本机测试,这里用10000,实际生产不要这么用Pipeline pipeline = jedis.pipelined(); 
  2. pipeline = jedis.pipelined();for (int i = 0; i < rehashThreshold; i++) { 
  3.     pipeline.setex(String.valueOf(i), expireTime, String.valueOf(i));    if (i % 10000 == 0) { 
  4.         pipeline.sync(); 
  5.     } 
  6. pipeline.sync();// 2.等待写增量TimeUnit.SECONDS.sleep(5);for (int i = rehashThreshold; i < rehashThreshold + 200; i++) { 
  7.     jedis.setex(String.valueOf(i), expireTime, String.valueOf(i)); 
  8.     TimeUnit.SECONDS.sleep(1); 

(2) 开始测试

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

  1. ​keys       mem      clients blocked requests            connections32766      4.69M    3       0       32797 (+2)          4 
  2. 32767      4.69M    3       0       32799 (+2)          4 
  3. 32768      4.69M    3       0       32801 (+2)          4 
  4. 32769      5.44M    3       0       32803 (+2)          4 

(b) 当阈值=220=1048576,从下面可以看出到key的个数为1048577时,内存涨了32M。因为rehash会扩容,所以新的哈希表中的槽位变为了221 * 2(因为每个key都设置了过期时间,expires表),指针为8个字节,221 ? 2 ? 8 = 225 = 32MB。

  1. ​keys       mem      clients blocked requests            connections1048574    128.69M  3       0       3364129 (+2)        16 
  2. 1048575    128.69M  3       0       3364131 (+2)        16 
  3. 1048576    128.69M  3       0       3364133 (+2)        16 
  4. 1048577    160.69M  3       0       3364135 (+2)        16 
  5. 1048578    160.69M  3       0       3364137 (+2)        16 

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

  1. ​keys       mem      clients blocked requests            connections67108862   9.70G    3       0       70473683 (+2)       18 
  2. 67108863   9.70G    3       0       70473685 (+2)       18 
  3. 67108864   9.70G    3       0       70473687 (+2)       18 
  4. 67108865   11.70G   3       0       70473689 (+2)       18 
  5. 67108866   11.70G   3       0       70473691 (+2)       18 
  6. 67108867   11.70G   3       0       70473693 (+2)       18 

回过来看r-bp1c15fd9b142d04的key和内存变化图,可以发现上面的规则是正确的:

4. 后续观察

17点时,rehash结束,内存降了增加的2G的一半。

五、总结

由于哈希表的特性,Redis 中键值数量大,不会对存取造成性能影响,但是会出现本文提到的问题。控制键个数有几个建议:无用的键值设置过期时间或者定期删除。优化键值设计:例如可以使用 ziplist hash合并优化部分字符串类型。未来改进:内核层面支持 rehash 的审计日志以及增强 rehash 的速度。

责任编辑:武晓燕 来源: 占小狼的博客
相关推荐

2019-04-15 13:15:12

数据库MySQL死锁

2017-12-19 14:00:16

数据库MySQL死锁排查

2021-11-23 21:21:07

线上排查服务

2019-06-10 15:20:18

2018-08-01 10:40:04

Redis内存增长

2018-11-13 10:44:23

Linux服务器双网卡网络

2023-01-04 18:32:31

线上服务代码

2023-04-06 07:53:56

Redis连接问题K8s

2020-11-02 09:48:35

C++泄漏代码

2022-07-13 08:31:18

React问题排查

2021-08-19 09:50:53

Java内存泄漏

2020-08-27 21:36:50

JVM内存泄漏

2019-04-11 09:17:14

网络故障路由汇总

2022-02-08 17:17:27

内存泄漏排查

2019-03-15 16:20:45

MySQL死锁排查命令

2021-05-13 08:51:20

GC问题排查

2019-02-20 09:29:44

Java内存邮件

2022-11-03 16:10:29

groovyfullGC

2019-06-19 08:59:52

数据库死锁堆栈

2022-02-08 16:17:41

MySQL主从复制数据库
点赞
收藏

51CTO技术栈公众号