memcache的内存回收机制

时间:2022-08-05 07:01:29

memcache不会释放内存,而是重新利用。

在缓存的清除方面,memcache是不释放已分配内存。当已分配的内存所在的记录失效后,这段以往的内存空间,memcache只会重复利用。

memcached的内存回收机制不是说你设置的key到了生命周期就自动从内存中清除的,这个时候必须有一个新的对象入驻请求这个大小的chunk或者 这个过期的对象被get的时候才会清除。

那当所有给memcache的内存都被占用了,这个时候,memcache有两个设置,要么报错,要么,就是用 LRU方法,把last recently used的数据清除出去,也就是删除近段时间最少使用的同规格chunk。
 
这个时候就会引发应外一个问题,就是当你chunk大小设置不合理的时候,比如slab20 chunk大小非常大,一开始占用了很多内存,但是之后不论是否过期,不被再次利用到的时候就一直处于内存中,这样,当比较小的slab1中的chunk 满了,也没有内存新建slab并分割和slab1同样规格的chunk的时候,memcached就要启动LRU,来清理这个slab下的数据。那这种情 况就会造成在内存的极大程度浪费和cache命中率下降,是某些关键性的数据总是在内存中进进出出,得不到持久的保存。
这个时候我们可以调整factor参数,让chunk的大小达到我们的需要,这个需要根据业务来做。
那slab数量,growth factor大小,LRU频率以及空间浪费情况可以估计出来如下结果:
growth factor↑ slab数量 ↓ LRU频率↓ 空降浪费↑
growth factor↓ slab数量 ↑ LRU频率↑ 空降浪费↓
 
关于LRU
我们知道c++里分配内存有两种方式,预先分配和动态分配,显然,预先分配内存会使程序比较快,但是它的缺点是不能有效利用内存,而动态分配可以有效利用 内存,但是会使程序运行效率下降,memcached的内存分配就是基于以上原理,显然为了获得更快的速度,有时候我们不得不以空间换时间。
我启动一个memcached进程,占用内存100m,再打开telnet,telnet localhost 11211,连接上memcache之后,输入stats  slabs,回车,出现如下数据:
STAT :chunk_size
STAT :chunks_per_page
STAT :total_pages
STAT :total_chunks
STAT :used_chunks
STAT :free_chunks
STAT :free_chunks_end
STAT :chunk_size
STAT :chunks_per_page
STAT :total_pages
STAT :total_chunks
STAT :used_chunks
STAT :free_chunks
STAT :free_chunks_end
STAT :chunk_size
STAT :chunks_per_page
STAT :total_pages
STAT :total_chunks
STAT :used_chunks
STAT :free_chunks
STAT :free_chunks_end

以上就是前3个slab得详细信息
chunk_size表示数据存放块得大小,chunks_per_page表示一个内存页page中拥有得chunk得数
量,total_pages表示每个slab下page得个数。total_chunks表示这个slab下chunk得总数(=total_pages
*
chunks_per_page),used_chunks表示该slab下已经使用得chunk得数量,free_chunks表示该slab下还可以
使用得chunks数量。

从上面得示例slab 1一共有1m得内存空间,而且现在已经被用完了,slab2也有1m得内存空间,也被用完了,slab3得情况依然如此。

而且从这3个slab中chunk得size可以看出来,第一个chunk为80b,第二个是100b,第3个是128b,基本上后一个是前一个得
1.25倍,但是这个增长情况我们是可以控制得,我们可以通过在启动时得进程参数 –f来修改这个值,比如说 –f
1.1表示这个增长因子为1.1,那么第一个slab中得chunk为80b得话,第二个slab中得chunk应该是80*1.1左右。

解释了这么多也该可以看出来我遇到得问题得原因了,如果还看不出来,那我再补充关键的一句:memcached中新的value过来存放的地址是
该value的大小决定的,value总是会被选择存放到chunk与其最接近的一个slab中,比如上面的例子,如果我的value是80b,那么我这
所有的value总是会被存放到1号slab中,而1号slab中的free_chunks已经是0了,怎么办呢,如果你在启动memcached的时候
没有追加-M(禁止LRU,这种情况下内存不够时会out of
memory),那么memcached会把这个slab中最近最少被使用的chunk中的数据清掉,然后放上最新的数据。这就解释了为什么我的内存还有
40%的时候LRU就执行了,因为我的其他slab中的chunk_size都远大于我的value,所以我的value根本不会放到那几个slab中,
而只会放到和我的value最接近的chunk所在的slab中(而这些slab早就满了,郁闷了)。这就导致了我的数据被不停的覆盖,后者覆盖前者。

问题找到了,解决方案还是没有找到,因为我的数据必须要求命中率时100%,我只能通过调整slab的增长因子和page的大小来尽量来使命中率
接近100%,但是并不能100%保证命中率是100%(这话怎么读起来这么别扭呢,自我检讨一下自己的语文水平),如果您说,这种方案不行啊,因为我的
memcached server不能停啊,不要紧还有另外一个方法,就是memcached-tool,执行move命令,如:move 3
1,代表把3号slab中的一个内存页移动到1号slab中,有人问了,这有什么用呢,比如说我的20号slab的利用率非常低,但是page却又很多,
比如200,那么就是200m,而2好slab经常发生LRU,明显page不够,我就可以move 20
2,把20号slab的一个内存页移动到2号slab上,这样就能更加有效的利用内存了(有人说了,一次只移动一个page,多麻烦啊?ahuaxuan
说,还是写个脚本,循环一下吧)。

有人说不行啊,我的memcache中的数据不能丢失啊,ok,试试新浪的memcachedb吧,虽然我没有用过,但是建议大家可以试试,它也使利用
memcache协议和berkeleyDB做的(写到这里,我不得不佩服danga了,我觉得它最大的贡献不是memcache
server本身,而是memcache协议),据说它被用在新浪的不少应用上,包括新浪的博客。

补充,stats slab命令可以查看memcached中slab的情况,而stats命令可以查看你的memcached的一些健康情况,比如说命中率之类的,示例如下:

STAT pid
STAT uptime
STAT time
STAT version 1.2.
STAT pointer_size
STAT curr_items
STAT total_items
STAT bytes
STAT curr_connections
STAT total_connections
STAT connection_structures
STAT cmd_get
STAT cmd_set
STAT get_hits
STAT get_misses
STAT bytes_read
STAT bytes_written
STAT limit_maxbytes

从上面的数据可以看到这个memcached进程的命中率很好,get_misses低达0个,怎么回事啊,因为这个进程使我刚启动的,我只用 telnet连了一下,所以curr_connections为1,而total_items为0,因为我没有放数据进去,get_hits为0,因为我 没有调用get方法,最后的结果就是misses当然为0,哇哦,换句话说命中率就是100%,又yy了。

该到总结的时候了,从这篇文章里我们可以得到以下几个结论:

结论一,memcached得LRU不是全局的,而是针对slab的,可以说是区域性的。

结论二,要提高memcached的命中率,预估我们的value大小并且适当的调整内存页大小和增长因子是必须的。

结论三,带着问题找答案理解的要比随便看看的效果好得多。

参考:http://ahuaxuan.iteye.com/blog/225692