如图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之间，并且根据业务缓存数据块大小而定。
