探尋 Redis 內存詭異增長的元兇
記一次 Redis 內存詭異增長,由于 一次 Redis Rehash 造成的內存暴增。
一、現象
- 實例名:r-bp1cxxxxxxxxxd04(主從)
- 時間:2017-11-16 12:26~12:27
- 問題:一分鐘內存上漲了2G,如下圖所示:
- 鍵值規模:6000萬左右
二、Redis內存分析
1. 內存組成
上圖中的內存統計的是Redis的info memory命令中的used_memory屬性,例如:
- redis> info memory# 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
每個屬性的詳細說明:
計算公式如下:
- 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
- Sampled67234427keysinthe keyspace!
- Totalkey length inbytesis1574032382(avg len 23.41)
- Biggeststringfound'CCARD_DEVICE_CARD_REF_MAP_KEY_016817000004209'has20862bytes
- Biggest list found 'CCARD_VALID_DEVICE_TRAIN_QUEUE_KEY'has51items
- Biggest hash found'CCARD_VALID_DEVICE_TRAIN_MAP_KEY'has51fields67234359 stringswith71767890bytes(100.00%of keys,avg size1.07)67listswith151items(00.00%of keys,avg size2.25)0setswith0members(00.00%of keys,avg size0.00)1hashswith51fields(00.00%of keys,avg size51.00)0zsetswith0members(00.00%of keys,avg size0.00)
(2) 鍵值個數增加?未發現鍵值有明顯變化
(3) 客戶端緩沖區
由于內存增上去后,長時間沒下落,如果是因為緩沖區問題,會從info clients找到明顯問題,執行后發現:
- id=80207 addr=10.xx.0.4:63920 fd=46 name= age=624 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80215 addr=10.xx.0.23:43489 fd=36 name= age=591 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80366 addr=10.xx.0.8:59785 fd=18 name= age=84 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=del read=0 write=0 type=user
- id=80356 addr=10.xx.0.33:32117 fd=13 name= age=114 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80064 addr=10.xx.59.4:53446 fd=38 name= age=1070 idle=1070 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL read=0 write=0 type=admin
- id=80276 addr=10.xx.0.23:48511 fd=8 name= age=387 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80188 addr=10.xx.0.33:16265 fd=42 name= age=681 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80326 addr=10.xx.0.32:59779 fd=16 name= age=209 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80065 addr=10.xx.59.4:53447 fd=45 name= age=1070 idle=1070 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL read=0 write=0 type=admin
- id=79936 addr=10.xx.0.22:10607 fd=30 name= age=1480 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80174 addr=10.xx.0.5:60914 fd=6 name= age=722 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80300 addr=10.xx.0.22:22757 fd=48 name= age=298 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80037 addr=10.xx.0.5:55189 fd=15 name= age=1143 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80330 addr=10.xx.0.8:48533 fd=17 name= age=199 idle=10 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=79896 addr=10.xx.0.30:26814 fd=11 name= age=1616 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80299 addr=10.xx.0.24:11227 fd=44 name= age=303 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80086 addr=10.xx.0.32:52526 fd=40 name= age=1002 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80202 addr=10.xx.0.33:16658 fd=26 name= age=636 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80256 addr=10.xx.0.24:60496 fd=19 name= age=448 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=79908 addr=10.xx.0.29:18975 fd=12 name= age=1583 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80365 addr=10.xx.0.29:46429 fd=14 name= age=85 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=79869 addr=10.xx.27.4:48455 fd=35 name= age=1700 idle=1700 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL read=0 write=0 type=admin
- id=80334 addr=10.xx.0.23:50012 fd=39 name= age=189 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80041 addr=10.xx.0.32:51107 fd=33 name= age=1132 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=79992 addr=10.xx.0.22:12068 fd=28 name= age=1289 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80251 addr=10.xx.0.30:44213 fd=23 name= age=468 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80006 addr=10.xx.0.2:45895 fd=31 name= age=1242 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80321 addr=10.xx.0.30:48048 fd=5 name= age=224 idle=3 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80381 addr=10.xx.0.8:13360 fd=22 name= age=24 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=del read=0 write=0 type=user
- id=80200 addr=10.xx.0.24:59183 fd=24 name= age=640 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80113 addr=10.xx.0.2:52492 fd=21 name= age=915 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=174 addr=11.216.117.242:53027 fd=9 name= age=281390 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=replconf read=0 write=0 type=admin
- id=79991 addr=10.xx.0.4:48412 fd=25 name= age=1296 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80301 addr=127.0.0.1:47869 fd=49 name= age=291 idle=261 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=strlen read=0 write=0 type=admin
- id=80047 addr=10.xx.59.4:53184 fd=41 name= age=1114 idle=1114 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL read=0 write=0 type=admin
- id=80236 addr=10.xx.0.5:62546 fd=47 name= age=516 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80364 addr=10.xx.0.4:18794 fd=7 name= age=85 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80175 addr=10.xx.0.4:62245 fd=29 name= age=718 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80336 addr=10.xx.0.29:45701 fd=50 name= age=180 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80050 addr=10.xx.59.4:53188 fd=43 name= age=1114 idle=1114 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL read=0 write=0 type=admin
- id=79765 addr=10.xx.0.2:33832 fd=37 name= age=2027 idle=177 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info read=0 write=0 type=user
- id=80170 addr=10.xx.0.2:57853 fd=20 name= age=728 idle=24 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping read=0 write=0 type=user
- id=80390 addr=127.0.0.1:49449 fd=27 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client read=0 write=0 type=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天過期時間int expireTime = 60 * 60 * 24;// rehash閾值 - 50為了方便觀察rehash內存變化int rehashThreshold = (int) Math.pow(2, 25) - 50;// 1.批量寫入:pipeline批量寫入,由于是本機測試,這里用10000,實際生產不要這么用Pipeline pipeline = jedis.pipelined();
- pipeline = jedis.pipelined();for (int i = 0; i < rehashThreshold; i++) {
- pipeline.setex(String.valueOf(i), expireTime, String.valueOf(i)); if (i % 10000 == 0) {
- pipeline.sync();
- }
- }
- pipeline.sync();// 2.等待寫增量TimeUnit.SECONDS.sleep(5);for (int i = rehashThreshold; i < rehashThreshold + 200; i++) {
- jedis.setex(String.valueOf(i), expireTime, String.valueOf(i));
- TimeUnit.SECONDS.sleep(1);
- }
(2) 開始測試
(a) 當閾值=215=32768,從下面可以看出到key的個數為32769時,內存漲了一些,但是還不明顯。
- keys mem clients blocked requests connections32766 4.69M 3 0 32797 (+2) 4
- 32767 4.69M 3 0 32799 (+2) 4
- 32768 4.69M 3 0 32801 (+2) 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。
- keys mem clients blocked requests connections1048574 128.69M 3 0 3364129 (+2) 16
- 1048575 128.69M 3 0 3364131 (+2) 16
- 1048576 128.69M 3 0 3364133 (+2) 16
- 1048577 160.69M 3 0 3364135 (+2) 16
- 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。
- keys mem clients blocked requests connections67108862 9.70G 3 0 70473683 (+2) 18
- 67108863 9.70G 3 0 70473685 (+2) 18
- 67108864 9.70G 3 0 70473687 (+2) 18
- 67108865 11.70G 3 0 70473689 (+2) 18
- 67108866 11.70G 3 0 70473691 (+2) 18
- 67108867 11.70G 3 0 70473693 (+2) 18
回過來看r-bp1c15fd9b142d04的key和內存變化圖,可以發現上面的規則是正確的:
4. 后續觀察
17點時,rehash結束,內存降了增加的2G的一半。
五、總結
由于哈希表的特性,Redis 中鍵值數量大,不會對存取造成性能影響,但是會出現本文提到的問題。
控制鍵個數有幾個建議:
- 無用的鍵值設置過期時間或者定期刪除。
- 優化鍵值設計:例如可以使用 ziplist hash合并優化部分字符串類型。
- 未來改進:內核層面支持 rehash 的審計日志以及增強 rehash 的速度。