如图1所示,当往Memcached写入500万的160 Bytes的数据项,内存利用率计算:59485199(bytes)/67108864(limit_maxbytes)=89%。内存利用率达到89%时,从evictions看到MC主动踢出很多缓存数据,为什么MC达到90%的内存利用率时开始踢出缓存数据?
要分析原因,我们首先要了解下Slab Allocation机制,可参考理解memcached的内存存储。
从图2 growth factor=1.25的Slab Allocation看到,160 Bytes的数据项选择192 Bytes的chunk,浪费32 Bytes内存。虽然Slab Allocation解决了malloc/free固有的内存碎片问题,却不能有效利用分配到的内存。
我们计算每个chunk的期望内存利用率:
120B的chunk放置的数据项期望长度是(96+120)/2=108,期望的内存利用率为108/120=90%;
152B的chunk放置的数据项期望长度是(120+152)/2=136,期望的内存利用率为136/152=89%;
......
n B的chunk放置的数据项期望长度是(n/1.25+n)/2=9n/10,期望的内存利用率为9n/10/n=90%;
所以,内存利用率到90%就意味growth factor=1.25的MC内存已经放满数据,在没有过期数据的情况下,保存新数据只能淘汰LRU(Least Recent Used)的数据。
推广到任意growth factor(gf),n Bytes的chunk放置的数据项期望长度是(n/gf+n)/2=(1+gf)n/(2*gf),期望的内存利用率为(1+gf)/(2*gf),比如:
gf=1.25,期望的内存利用率为90%;
gf=2,期望的内存利用率为75%;
.......
极端情况,gf=1,期望的内存利用率为100%,但是growth factor必须大于1,否则会如图3的报错。
那是不是说growth factor接近1,期望的内存利用率就能接近100%?结果出人意料。
在分配64M内存的MC中,growth factor=1.000001,如图4、图5所示,1~199个Slab class的chunk size为96 Bytes,第200个Slab class的chunk size为1MB。
当growth factor=1.000001,往64M内存MC插入163 Bytes的数据项,如图6和图7所示,内存利用率:bytes(10432)/limit_maxbytes(67108864)=0.01%,趋近于0。163 Bytes的数据项不能放入到96 Bytes的chunk,只能放到slab class 200的64MB的chunk,几乎浪费64M所有的空间,总共写入163 Bytes * 64=10432 Bytes的数据。从这个例子看出,growth factor不能趋近与1,否则内存利用率趋近于0。但是growth factor也不能太大,否则内存利用率也会很低。
实践经验表明,growth factor最好介于1.05~2之间,并且根据业务缓存数据块大小而定。