1功能简述
1.1Automove功能背景
因为这种模式带来的问题也会随着实例的运行时间的增加而凸显。假设实例在运行初期，业务模型存放的都是1k大小的value值，并且把memcache的内存耗尽。此时，memcache的内部全部都是1k类型的slab。随着业务发展value大小变化到了2k，此时需要2k类型的slab存放，这时memcache就会在一个2k类型的page内不断evict为新的key腾出空间。而之前已经分配完毕的1k-slab则毫无用途。这样的情况显然会造成内存使用的不合理，和2k类型key的命中率大幅度降低，以及memcachedeviction计数器大量增加的情况。
memcache为了解决因slab引起的内存使用不合理的问题，在1.4.11中引入了slabautomove的功能。本文将围绕这个功能进行功能和性能上的测试。 slabautomove实现原理简单叙述如下：
1.2Automove功能的使用
automove分配手动重分配和自动重分配。
手动：
memcache启动时加上参数：memcached-oslab_reassign
cache运行时，执行以下命令：
| echo"slabsreassign14"|nclocalhost11211 |
自动重分配：
memcache启动时加上参数：memcached-oslab_reassign,slab_automove
之后cache就会以每10秒一次的频率进行重分配。
也可以临时停止自动重分配：echo"slabsautomove0"|nclocalhost11211
2测试过程和结果分析
2.1测试环境
操作系统：CentOSrelease6.3(Final) 内核版本：2.6.32-279.el6.x86_64
| CPU：Intel(R)Xeon(R)CPUE5-26700@2.60GHz |
memcache版本：1.4.15
memcache内存：128M
2.2测试方法
测试通过多个并发访问memcache，记录响应时间后作图的方式进行比较。 测试脚本为自己编写的perl脚本。主要步骤如下：
从一个并发到二十并发循环进行以下操作
slab预分配（保证内存被某种slab耗尽）
slab超时get（清空之前所有的slab，并保证之前分配的slab类型不变）
测试正式开始
预分配slab类型的set，并记录响应时间，作为比较基准
新slab类型的set，并记录响应时间，作为比较对象
2.3slab富裕vsslab紧张
测试目的：分析slab类型紧张和富裕时的set响应时间是否有差异，来说明当某个slab类型紧缺时是否会对前端业务产生响应时间的影响
从下图的测试结果可以看到当slab类型分配紧张时的set响应时间明显高于slab类型分配富裕的时候。从理论上也比较容易理解这个结果。因为当该类型的所有slab均满的时候，memcache需要做LRUlist上的eviction才能腾出空间记录新的key，而这个额外步骤也造成了set响应时间的增加。
2.4automove开启（未使用）vsautomove关闭
测试目的：由于automove是由一个额外的异步线程实现的功能。因此这个测试通过比较功能的开关是否会对set响应时间有影响，来说明额外线程是否有额外性能损耗。
从第一章的介绍可以看出，slab的automove是一个10秒循环的异步线程管理的。因此当测试时间少于10秒时，就可以模拟automove开启但未使用的情况。
测试结果：从下图可以看到，后台线程的存在对原有响应时间的pattern并没有很大的影响。因此，开启slabautomove后在没有使用的情况下，没有不良影响
2.5automove开启（且使用）vsautomove关闭
测试目的：这个测试用于观察automove开启后，slab类型重新分配后对性能是否能带来显著提升。
测试结果：从下图可以看出，相较automove关闭时，slab的重新分配确实能够带来一定程度上响应时间的提升。但效果并不明显，主要是因为slab的重新分配只是10秒一次的后台作业，需要一段非常长的时间后，slab的类型才能趋于合理稳定。当然automove的主要目的并不在于直接提高cache的响应速度，而在于slab分配合理后，key的命中率能有一定程序的提高，减少后端数据库和service的访问压力。 从测试结束后的slab情况来看，开启automove后，因为测试时间较短，只有少量slab被重新分配。
| memcached-toollocalhost:11211display #Item_SizeMax_agePagesCountFull?EvictedEvict_TimeOOM 121.2K9s120106072yes000 131.4K0s85664yes7405100 |
3测试结论
以下是测试的主要结论：
因为slab不足的cachemiss的响应时间，会比cachehit的响应时间略多
开启automove后台线程对于响应时间没有副作用
开启automove对于cache访问的响应时间提升有限
开启automove的主要意义在于合理使用内存，提升key的命中率，降低后端系统压力
综上，认为automove可以比较放心的在线上开启使用
