Memcache Slab Eviction 功能测试

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响应时间的增加。

Memcache Slab Eviction 功能测试

2.4 automove开启 (未使用)vs automove关闭

测试目的:由于automove是由一个额外的异步线程实现的功能。因此这个测试通过比较功能的开关是否会对set响应时间有影响,来说明额外线程是否有额外性能损耗。

从第一章的介绍可以看出,slab的automove是一个10秒循环的异步线程管理的。因此当测试时间少于10秒时,就可以模拟automove开启但未使用的情况。

测试结果:从下图可以看到, 后台线程的存在对原有响应时间的pattern并没有很大的影响。因此,开启slab automove后在没有使用的情况下,没有不良影响

Memcache Slab Eviction 功能测试

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

Memcache Slab Eviction 功能测试

3 测试结论

以下是测试的主要结论:

  • 因为slab不足的cache miss的响应时间,会比cache hit的响应时间略多

  • 开启automove后台线程对于响应时间没有副作用

  • 开启automove对于cache访问的响应时间提升有限

  • 开启automove的主要意义在于合理使用内存,提升key的命中率,降低后端系统压力

综上,认为automove可以比较放心的在线上开启使用。

 
 
上一篇:基于表单布局:分析过时的table结构与当下的div结构


下一篇:[WPF自定义控件库]简单的表单布局控件