Redis的内存碎片

Redis默认使用jemalloc分配内存,根据fast'14的最佳论文的说法,当遇到变长key-value负载时,会出现碎片问题:内存利用率低,实际分配的内存比所需要的内存多。因此我用YCSB对Redis的内存进行了测试。

  • 实验的第1阶段:向Redis插入100万条记录,key为20字节,value为100字节,皆为定长,理论上的有效数据大约是120MB。
  • 阶段2:产生90万个update请求,请求为均匀随机分布(每个key被选中的概率相等),key值不变,但value变为130字节。一次update相当于删除原来的100字节,再插入一个130字节。
  • 阶段3:产生90万个update请求,value变为170字节。
  • 阶段4:产生90万个update请求,value变为210字节。
  • 接着12个阶段,每次都是90万个update请求,value长度渐增。
  • 最后一个阶段不产生任何请求,重启redis。

然后每一阶段结束后,都使用info命令查看redis的内存情况,结果如下图所示。

image

used代表redis使用jemalloc分配的内存,rss代表了进程当前占用的内存(可以看做jemalloc实际分配了多少内存)。rss/used可以作为衡量碎片的指标,越大说明碎片越严重。

可以看到随着value不断增大,redis需要分配的内存线性增长。rss的增长比used更快,因此内存碎片的问题的确存在,rss/used甚至一度超过了2.0(440字节时达到最高值为2.06),这意味着redis每用1GB内存都需要额外多付出1GB。顶峰过后,rss/used下降到了1.6左右。如果我们重启redis,碎片将不再存在。

一个值得注意的问题是,redis使用的内存比实际的数据量多很多。比如第一阶段后,有效数据应为120MB,但redis却分配了525.4MB的内存。其它阶段也有类似现象。具体原因还不清楚,但我感觉有点多。因此除了jemalloc存在的碎片问题,redis本身是否在使用内存时过于土豪?

我还尝试测试了千万条记录的实验,测试方法和百万记录完全一致。但在我的16GB内存的服务器上,实验几乎无法进行,在第2、3个阶段时,redis就会报无法分配内存的错误,导致实验失败。我的猜测是redis的rdb机制使用了copy-on-write,在我们这么高的update负载下,redis需要两倍内存才能完成rdb。

因此我关闭了rdb再进行实验。这次实验可以跑到第8个阶段(370字节),但在第9个阶段时,出现无法分配内存的错误,因为redis使用的内存超过了物理内存。我们来看看第9个阶段的有效数据量,最坏的情况是900万个410+20的key value,100万个370+20的key value,差不多4GB的数据量。但redis在关闭rdb的情况下却无法完成任务!(考虑到这时rss/used接近2了,就算没有任何开销,也需要8GB的内存)

实际的情况是:上述的实验有一些极端,实际的负载可能没有这么变态。因此我测试了facebook公布的负载(即key的长度服从极值分布,value的长度服从帕累托分布),结果发现jemalloc没有出现任何内存碎片问题,rss/used一直是1.03左右。因此内存碎片问题可能存在,但有多严重,得看负载。

展开阅读全文

没有更多推荐了,返回首页