Redis 記憶體容量的預估和最佳化

Redis是個記憶體全集的kv資料庫,不存在部分資料在磁碟部分資料在記憶體裡的情況,所以提前預估和節約記憶體非常重要.本文將以最常用的string和zipmap兩類資料結構在jemalloc記憶體 Clerk下的記憶體容量預估和節約記憶體的方法.

先說說jemalloc,傳說中解決firefox記憶體問題freebsd的預設malloc分配器,area,thread-cache功能和tmalloc非常的相識.在2.4版本被Redis引入,在antirez的博文中 提到內節約30%的記憶體使用量.相比glibc的malloc需要在每個記憶體外附加一個額外的4位元組記憶體塊,jemalloc可以通過 je_malloc_usable_size函數獲得指標實際指向的記憶體大小,這樣Redis裡的每個key或者value都可以節約4個位元組,不少阿.

下面是jemalloc size class categories,左邊是使用者申請記憶體範圍,右邊是實際申請的記憶體大小.這張表後面會用到.

1     - 4     size class:4
5     - 8     size class:8
9     - 16    size class:16
17    - 32    size class:32
33    - 48    size class:48
49    - 64    size class:64
65    - 80    size class:80
81    - 96    size class:96
97    - 112   size class:112
113   - 128   size class:128
129   - 192   size class:192
193   - 256   size class:256
257   - 320   size class:320
321   - 384   size class:384
385   - 448   size class:448
449   - 512   size class:512
513   - 768   size class:768
769   - 1024  size class:1024
1025  - 1280  size class:1280
1281  - 1536  size class:1536
1537  - 1792  size class:1792
1793  - 2048  size class:2048
2049  - 2304  size class:2304
2305  - 2560  size class:2560string
string類型看似簡單,但還是有幾個可最佳化的點.先來看一個簡單的set命令所添加的資料結構.

 

一個set hello world命令最終(中間會malloc,free的我們不考慮)會產生4個對象,一個dictEntry(12位元組),一個sds用於儲存key,還有 一個redisObject(12位元組),還有一個儲存string的sds.sds對象除了包含字串本生之外,還有一個sds header和額外的一個位元組作為字串結尾共9個位元組.

sds.c
========
 51 sds sdsnewlen(const void *init, size_t initlen) {
 52     struct sdshdr *sh;
 53
 54     sh = zmalloc(sizeof(struct sdshdr)+initlen+1);

sds.h
=======
 39 struct sdshdr {
 40     int len;
 41     int free;
 42     char buf[];
 43
};根據jemalloc size class那張表,這個命令最終申請的記憶體為16(dictEtnry) + 16 (redisObject) + 16(“hello”) + 16(“world”),一共64位元組.注意如果key或者value的字串長度+9位元組超過16位元組,則實際申請的記憶體大小32位元組.

提一下string常見的最佳化方法

盡量使value為純數字
這樣字串會轉化成int類型減少記憶體的使用.

redis.c
=========
37 void setCommand(redisClient *c) {
38   c->argv[2] = tryObjectEncoding(c->argv[2]);
39   setGenericCommand(c,0,c->argv[1],c->argv[2],NULL);
40 }
object.c =======
275   o->encoding = REDIS_ENCODING_INT;
276   sdsfree(o->ptr);
277   o->ptr = (void*) value;可以看到sds被釋放了,數字被儲存在指標位上,所以對於set hello 1111111就只需要48位元組的記憶體.

調整REDIS_SHARED_INTEGERS
如果value數字小於宏REDIS_SHARED_INTEGERS(預設10000),則這個redisObject也都節省了,使用redis Server啟動時的share Object.

object.c
=======
269 if (server.maxmemory == 0 && value >= 0 && value < REDIS_SHARED_INTEGERS &&
270   pthread_equal(pthread_self(),server.mainthread)) {
271   decrRefCount(o);
272   incrRefCount(shared.integers[value]);
273   return shared.integers[value];
274 }這樣一個set hello 111就只需要32位元組,連redisObject也省了.所以對於value都是小數位應用,適當調大REDIS_SHARED_INTEGERS這個宏可以很好的節約記憶體.

出去kv之外,dict的bucket逐漸層大也需要消耗記憶體,bucket的元素是個指標(dictEntry**), 而bucket的大小是超過key個數向上求整的2的n次方,對於1w個key如果rehash過後就需要16384個bucket.

開始string類型的容量預估測試, 指令碼如下

#! /bin/bash

redis-cli info|grep used_memory:

for (( start = 10000; start < 30000; start++ ))
do
    redis-cli set a$start baaaaaaaa$start > /dev/null
done

redis-cli info|grep used_memory:根據上面的總結我們得出string公式

string類型的記憶體大小 = 索引值個數 * (dictEntry大小 + redisObject大小 + 包含key的sds大小 + 包含value的sds大小) + bucket個數 * 4

下面是我們的預估值

>>> 20000 * (16 + 16 + 16 + 32) + 32768 * 4
1731072運行一下測試指令碼

hoterran@~/Projects/redis-2.4.1$ bash redis-mem-test.sh
used_memory:564352
used_memory:2295424計算一下差值

>>> 2295424 - 564352
1731072都是1731072,說明預估非常的準確, ^_^

zipmap
這篇文章已經解釋zipmap的 效果,可以大量的節約記憶體的使用.對於一個普通的subkey和value,只需要額外的3個位元組(keylen,valuelen,freelen)來 儲存,另外的hash key也只需要額外的2個位元組(zm頭尾)來儲存subkey的個數和結束符.

 

zipmap類型的記憶體大小 = hashkey個數 * (dictEntry大小 + redisObject大小 + 包含key的sds大小 + subkey的總大小) + bucket個數 * 4

開始容量預估測試,100個hashkey,其中每個hashkey裡包含300個subkey, 這裡key+value的長度為5位元組

#! /bin/bash

redis-cli info|grep used_memory:

for (( start = 100; start < 200; start++ ))
do
    for (( start2 = 100; start2 < 400; start2++ ))
    do
         redis-cli hset test$start a$start2 "1" > /dev/null
    done
done

redis-cli info|grep used_memory:這裡subkey是同時申請的的,大小是300 * (5 + 3) + 2 =2402位元組,根據上面jemalloc size class可以看出實際申請的記憶體為2560.另外100hashkey的bucket是128.所以總的預估大小為

>>> 100 * (16 + 16 + 16 + 2560) + 128 * 4
261312運行一下上面的指令碼

hoterran@~/Projects/redis-2.4.1$ bash redis-mem-test-zipmap.sh
used_memory:555916
used_memory:817228計算一下差值

>>> 817228 - 555916
261312是的完全一樣,預估很準確.

另外扯扯zipmap的一個缺陷,zipmap用於記錄subkey個數的zmlen只有一個位元組,超過254個subkey後則無法記錄,需要遍 曆整個zipmap才能獲得subkey的個數.而我們現在常把hash_max_zipmap_entries設定為1000,這樣超過254個 subkey之後每次hset效率都很差.

354     if (zm[0] < ZIPMAP_BIGLEN) {
355         len = zm[0];                       //小於254,直接返回結果
356     } else {
357         unsigned char *p = zipmapRewind(zm);   //遍曆zipmap
358         while((p = zipmapNext(p,NULL,NULL,NULL,NULL)) != NULL) len++;
359
360         /* Re-store length if small enough */
361         if (len < ZIPMAP_BIGLEN) zm[0] = len;
362     }簡單把zmlen設定為2個位元組(可以儲存65534個subkey)可以解決這個問題,今天和antirez聊了一下,這會破壞rdb的相容性,這個功能改進延遲到3.0版本,另外這個缺陷可能是weibo的Redis機器cpu消耗過高的原因之一.

文章出處：http://blog.nosqlfan.com/html/3430.html