Memcache Slab Eviction 功能测试
1 功能简述
1.1 Automove功能背景
由于memcache的内存分配是基于slab的，每个1M的page内只能存放对应slab大小范围的value值。具体原理见：http://dev.mysql.com/doc/refman/5.0/en/ha-memcached-using-memory.html 。
因为这种模式带来的问题也会随着实例的运行时间的增加而凸显。假设实例在运行初期，业务模型存放的都是1k大小的value值，并且把memcache的内存耗尽。此时，memcache的内部全部都是1k类型的slab。随着业务发展value大小变化到了2k，此时需要2k类型的slab存放，这时memcache就会在一个2k类型的page内不断evict为新的key腾出空间。而之前已经分配完毕的1k-slab则毫无用途。这样的情况显然会造成内存使用的不合理，和2k类型key的命中率大幅度降低，以及memcached eviction计数器大量增加的情况。
memcache为了解决因slab引起的内存使用不合理的问题，在1.4.11中引入了slab automove的功能。本文将围绕这个功能进行功能和性能上的测试。
slab automove实现原理简单叙述如下：
The algorithm is slow and conservative. If a slab class is seen as having the highest eviction count 3 times 10 seconds apart, it will take a page from a slab class which has had zero evictions in the last 30 seconds and move the memory. （摘自memcache wiki，详见http://code.google.com/p/memcached/wiki/ReleaseNotes1411）
1.2 Automove 功能的使用
automove分配手动重分配和自动重分配。
手动：
memcache启动时加上参数：memcached -o slab_reassign
cache运行时，执行以下命令：
echo "slabs reassign 1 4" | nc localhost 11211
自动重分配：
memcache启动时加上参数：memcached -o slab_reassign,slab_automove
之后cache就会以每10秒一次的频率进行重分配。
也可以临时停止自动重分配：echo "slabs automove 0" | nc localhost 11211
2 测试过程和结果分析
2.1 测试环境
操作系统：CentOS release 6.3 (Final)
内核版本：2.6.32-279.el6.x86_64
CPU：Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
memcache版本：1.4.15
memcache内存：128M
2.2 测试方法
测试通过多个并发访问memcache，记录响应时间后作图的方式进行比较。
测试脚本为自己编写的perl脚本。主要步骤如下：
从一个并发到二十并发循环进行以下操作
-
slab预分配（保证内存被某种slab耗尽）
-
slab 超时get（清空之前所有的slab，并保证之前分配的slab类型不变）
-
测试正式开始
-
预分配slab类型的set，并记录响应时间，作为比较基准
-
新slab类型的set ，并记录响应时间，作为比较对象
2.3 slab富裕 vs slab紧张
测试目的：分析slab类型紧张和富裕时的set响应时间是否有差异，来说明当某个slab类型紧缺时是否会对前端业务产生响应时间的影响
从下图的测试结果可以看到当slab类型分配紧张时的set响应时间明显高于slab类型分配富裕的时候。从理论上也比较容易理解这个结果。因为当该类型的所有slab均满的时候，memcache需要做LRU list上的eviction才能腾出空间记录新的key，而这个额外步骤也造成了set响应时间的增加。
2.4 automove开启 （未使用）vs automove关闭
测试目的：由于automove是由一个额外的异步线程实现的功能。因此这个测试通过比较功能的开关是否会对set响应时间有影响，来说明额外线程是否有额外性能损耗。
从第一章的介绍可以看出，slab的automove是一个10秒循环的异步线程管理的。因此当测试时间少于10秒时，就可以模拟automove开启但未使用的情况。
测试结果：从下图可以看到， 后台线程的存在对原有响应时间的pattern并没有很大的影响。因此，开启slab automove后在没有使用的情况下，没有不良影响
2.5 automove开启（且使用） vs automove关闭
测试目的：这个测试用于观察automove开启后，slab类型重新分配后对性能是否能带来显著提升。
测试结果：从下图可以看出，相较automove关闭时，slab的重新分配确实能够带来一定程度上响应时间的提升。但效果并不明显，主要是因为slab的重新分配只是10秒一次的后台作业，需要一段非常长的时间后，slab的类型才能趋于合理稳定。当然automove的主要目的并不在于直接提高cache的响应速度，而在于slab分配合理后，key的命中率能有一定程序的提高，减少后端数据库和service的访问压力。
从测试结束后的slab情况来看，开启automove后，因为测试时间较短，只有少量slab被重新分配。
memcached-tool localhost:11211 display
# Item_Size Max_age Pages Count Full? Evicted Evict_Time OOM
12 1.2K 9s 120 106072 yes 0 0 0
13 1.4K 0s 8 5664 yes 74051 0 0
3 测试结论
以下是测试的主要结论：
-
因为slab不足的cache miss的响应时间，会比cache hit的响应时间略多
-
开启automove后台线程对于响应时间没有副作用
-
开启automove对于cache访问的响应时间提升有限
-
开启automove的主要意义在于合理使用内存，提升key的命中率，降低后端系统压力
综上，认为automove可以比较放心的在线上开启使用。