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的内存情况，结果如下图所示。

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左右。因此内存碎片问题可能存在，但有多严重，得看负载。

Redis的内存碎片