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的内存情况，结果如下图所示。
used代表redis使用jemalloc分配的内存，rss代表了进程当前占用的内存（可以看做jemalloc实际分配了多少内存）。rss/used可以作为衡量碎片的指标，越大说明碎片越严重。
可以看到随着value不断增大，redis需要分配的内存越来越多。内存碎片的问题的确存在，rss/used甚至一度超过了2.0（440字节时达到最高值为2.06），这意味着redis每用1GB内存都需要额外多付出1GB。顶峰过后，rss/used下降到了1.6左右。最后我们重启redis，rss/used=1.03。
我们知道Redis并没有自己实现内存池，没有在标准的系统内存分配器上再加上自己的东西。所以系统内存分配器的性能及碎片率会对Redis造成一些性能上的影响。
在Redis的 zmalloc.c 源码中，我们可以看到如下代码：
48 /* Explicitly override malloc/free etc when using tcmalloc. */ 49 #if defined(USE_TCMALLOC) 50 #define malloc(size) tc_malloc(size) 51 #define calloc(count,size) tc_calloc(count,size) 52 #define realloc(ptr,size) tc_realloc(ptr,size) 53 #define free(ptr) tc_free(ptr) 54 #elif defined(USE_JEMALLOC) 55 #define malloc(size) je_malloc(size) 56 #define calloc(count,size) je_calloc(count,size) 57 #define realloc(ptr,size) je_realloc(ptr,size) 58 #define free(ptr) je_free(ptr) 59 #endif从上面的代码中我们可以看到，Redis在编译时，会先判断是否使用tcmalloc，如果是，会用tcmalloc对应的函数替换掉标准的libc中的函数实现。其次会判断jemalloc是否使得，最后如果都没有使用才会用标准的libc中的内存管理函数。
而在最新的2.4.4版本中，jemalloc已经作为源码包的一部分包含在源码包中，所以可以直接被使用。而如果你要使用tcmalloc的话，是需要自己安装的。
下面简单说一下如何安装tcmalloc包，tcmalloc是google-proftools中的一部分，所以我们实际上需要安装google-proftools。如果你是在64位机器上进行安装，需要先安装其依赖的libunwind库。
wget http://download.savannah.gnu.org/releases/libunwind/libunwind-0.99-alpha.tar.gz tar zxvf libunwind-0.99-alpha.tar.gz cd libunwind-0.99-alpha/ CFLAGS=-fPIC ./configure make CFLAGS=-fPIC make CFLAGS=-fPIC install然后再进行google-preftools的安装：
wget http://google-perftools.googlecode.com/files/google-perftools-1.8.1.tar.gz tar zxvf google-perftools-1.8.1.tar.gz cd google-perftools-1.8.1/ ./configure --disable-cpu-profiler --disable-heap-profiler --disable-heap-checker --disable-debugalloc --enable-minimal make && make install sudo echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf #如果没有这个文件，自己建一个 sudo /sbin/ldconfig然后再进行Redis的安装，在make时指定相应的参数以启用tcmalloc
$ curl -O http://redis.googlecode.com/files/redis-2.4.4.tar.gz $ tar xzvf redis-2.4.4.tar.gz $ cd redis-2.4.4 $ make USE_TCMALLOC=yes FORCE_LIBC_MALLOC=yes $ sudo make install再启动Redis后通过info命令就能看到使用的内存分配器了。
下面回到本文的主题，对于tcmalloc，jemalloc和libc对应的三个内存分配器。其性能和碎片率如何呢？下面是一个简单测试结果，使用Redis自带的redis-benchmark写入等量数据进行测试，数据摘自采用不同分配器时Redis info信息。我们可以看到，采用tcmalloc时碎片率是最低的，为1.01，jemalloc为1.02，而libc的分配器碎片率为1.31，如下所未：
used_memory:708391440 used_menory_human:675.57M used_memory_rss:715169792 used_memory_peak:708814040 used_memory_peak_human:675.98M mem_fragmentation_ratio:1.01mem_allocator:tcmalloc-1.7used_memory:708381168 used_menory_human:675.56M used_memory_rss:723587072 used_memory_peak:708803768 used_memory_peak_human:675.97M mem_fragmentation_ratio:1.02mem_allocator:jemalloc-2.2.1used_memory:869000400 used_menory_human:828.74M used_memory_rss:1136689152 used_memory_peak:868992208 used_memory_peak_human:828.74M mem_fragmentation_ratio:1.31mem_allocator:libc上面的测试数据都是小数据，也就是说单条数据并不大，下面我们尝试设置benchmark的-d参数，将value值调整为1k大小，测试结果发生了一些变化：
used_memory:830573680 used_memory_human:792.10M used_memory_rss:849068032 used_memory_peak:831436048 used_memory_peak_human:792.92M mem_fragmentation_ratio:1.02mem_allocator:tcmalloc-1.7used_memory:915911024 used_memory_human:873.48M used_memory_rss:927047680 used_memory_peak:916773392 used_memory_peak_human:874.30M mem_fragmentation_ratio:1.01mem_allocator:jemalloc-2.2.1used_memory:771963304 used_memory_human:736.20M used_memory_rss:800583680 used_memory_peak:772784056 used_memory_peak_human:736.98M mem_fragmentation_ratio:1.04mem_allocator:libc可以看出，在分配大块内存和小块内存上，几种分配器的碎片率差距还是比较大的，大家在使用Redis的时候，还是尽量用自己真实的数据去做测试，以选择最适合自己数据的分配器。