轉(zhuǎn)載:探尋 Redis 內(nèi)存詭異增長的元兇

記一次 Redis 內(nèi)存詭異增長，由于 一次?Redis?Rehash 造成的內(nèi)存暴增。

一、現(xiàn)象

實例名：r-bp1cxxxxxxxxxd04(主從)

時間：2017-11-16 12:26~12:27

問題：一分鐘內(nèi)存上漲了2G，如下圖所示：

鍵值規(guī)模：6000萬左右

二、Redis內(nèi)存分析

1. 內(nèi)存組成

上圖中的內(nèi)存統(tǒng)計的是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_memoryRedis 分配器分配的內(nèi)存量，也就是實際存儲數(shù)據(jù)的內(nèi)存總量

used_memory_human以可讀格式返回 Redis 使用的內(nèi)存總量

used_memory_rss從操作系統(tǒng)的角度，Redis進程占用的總物理內(nèi)存

used_memory_peak內(nèi)存分配器分配的最大內(nèi)存，代表used_memory的歷史峰值

used_memory_peak_human以可讀的格式顯示內(nèi)存消耗峰值

used_memory_luaLua引擎所消耗的內(nèi)存

mem_fragmentation_ratioused_memory_rss /used_memory比值，表示內(nèi)存碎片率

mem_allocatorRedis 所使用的內(nèi)存分配器。默認: jemalloc

計算公式如下：

used_memory = 自身內(nèi)存+對象內(nèi)存+緩沖內(nèi)存+lua內(nèi)存used_rss = used_memory + 內(nèi)存碎片

如下圖所示：

2. 內(nèi)存分析

(1) 自身內(nèi)存：一個空的Redis占用很小，可以忽略不計

(2) kv內(nèi)存：key對象 + value對象

(3) 緩沖區(qū)：客戶端緩沖區(qū)(普通 + slave偽裝 + pubsub)以及aof緩沖區(qū)(比較固定，一般沒問題)

(4) Lua：Lua引擎所消耗的內(nèi)存

3. 內(nèi)存突增常見問題

(1) kv內(nèi)存：bigkey、大量寫入

(2) 客戶端緩沖區(qū)：一般常見的有普通客戶端緩沖區(qū)(例如monitor命令)或者pubsub客戶端緩沖區(qū)

三、問題排查

(1) bigkey ? 經(jīng)掃描未發(fā)現(xiàn)bigkey

Sampled 67234427 keys in the keyspace!

Total key length in bytes is 1574032382 (avg len 23.41)

Biggest string found 'CCARD_DEVICE_CARD_REF_MAP_KEY_016817000004209' has 20862 bytes

Biggest ? list found 'CCARD_VALID_DEVICE_TRAIN_QUEUE_KEY' has 51 items

Biggest ? hash found 'CCARD_VALID_DEVICE_TRAIN_MAP_KEY' has 51 fields67234359 strings with 71767890 bytes (100.00% of keys, avg size 1.07)67 lists with 151 items (00.00% of keys, avg size 2.25)0 sets with 0 members (00.00% of keys, avg size 0.00)1 hashs with 51 fields (00.00% of keys, avg size 51.00)0 zsets with 0 members (00.00% of keys, avg size 0.00)

(2) 鍵值個數(shù)增加？未發(fā)現(xiàn)鍵值有明顯變化

(3) 客戶端緩沖區(qū)

由于內(nèi)存增上去后，長時間沒下落，如果是因為緩沖區(qū)問題，會從info clients找到明顯問題，執(zhí)行后發(fā)現(xiàn)：

redis> info clients# Clientsconnected_clients:43client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0admin_clients:6rejected_vpc_conn_count:0close_idle_unknown_conn_count:0

執(zhí)行client中也沒有明顯的omem大于0的情況

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存儲結(jié)構(gòu)

如下圖所示，Redis的所有kv保存在dict中，其中ht對應兩個哈希表ht[0]和ht[1]，平時一個空閑，一個用于存儲數(shù)據(jù)，只有當需要rehash時，ht[1]才會用到。

2. Redis的字典rehash

為了保證哈希表的負載，當哈希表的元素個數(shù)等于哈希表槽數(shù)時候，會進行rehash擴容。擴容后h[1]的容量等于第一個大于等于ht[0].size*2的2n，例如hash表的初始化容量是4，那么下一次擴容就是8，以此類推。

3. 測試

(1) 測試方法

先批量寫入到rehash閾值附近，然后在逐條去寫，觀察內(nèi)存變化

// 為每個鍵設(shè)置1天過期時間int expireTime = 60 * 60 * 24;// rehash閾值 - 50為了方便觀察rehash內(nèi)存變化int rehashThreshold = (int) Math.pow(2, 25) - 50;// 1.批量寫入：pipeline批量寫入，由于是本機測試，這里用10000，實際生產(chǎn)不要這么用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的個數(shù)為32769時，內(nèi)存漲了一些，但是還不明顯。

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的個數(shù)為1048577時，內(nèi)存漲了32M。因為rehash會擴容，所以新的哈希表中的槽位變?yōu)榱?21* 2（因為每個key都設(shè)置了過期時間，expires表），指針為8個字節(jié)，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的個數(shù)為67108865時，內(nèi)存漲了2GB。因為rehash會擴容，所以新的哈希表中的槽位變?yōu)榱?27* 2（因為每個key都設(shè)置了過期時間，expires表），指針為8個字節(jié)，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和內(nèi)存變化圖，可以發(fā)現(xiàn)上面的規(guī)則是正確的：

4. 后續(xù)觀察

17點時，rehash結(jié)束，內(nèi)存降了增加的2G的一半。

五、總結(jié)

由于哈希表的特性，Redis 中鍵值數(shù)量大，不會對存取造成性能影響，但是會出現(xiàn)本文提到的問題?？刂奇I個數(shù)有幾個建議：無用的鍵值設(shè)置過期時間或者定期刪除。優(yōu)化鍵值設(shè)計：例如可以使用 ziplist hash合并優(yōu)化部分字符串類型。未來改進：內(nèi)核層面支持 rehash 的審計日志以及增強 rehash 的速度。

更多精彩文章，盡在「服務(wù)端思維」！

推薦閱讀