Redis默认使用jemalloc分配内存，根据fast
Redis默认使用jemalloc分配内存，根据fast’14的最佳论文的说法，当遇到变长key-value负载时，会出现碎片问题：内存利用率低，实际分配的内存比所需要的内存多。因此我用YCSB对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左右。因此内存碎片问题可能存在，，但有多严重，得看负载。
Ubuntu 14.04下Redis安装及简单测试
Redis集群明细文档
Ubuntu 12.10下安装Redis（图文详解）+ Jedis连接Redis
Redis系列-安装部署维护篇
CentOS 6.3安装Redis
Redis安装部署学习笔记
Redis配置文件redis.conf 详解
Redis 的详细介绍：请点这里
本文来源gaodai#ma#com搞@@代~&码*网2Redis 的下载地址：请点这里
本文永久更新链接地址：
转载请注明原文链接：Redis的内存碎片
