memcached 命中率

Memcached，人所皆知的remote distribute cache（不知道的可以javaeye一下下，或者google一下下，或者baidu一下下，但是鉴于baidu的排名商业味道太浓（从最近得某某事件可以看出），所以还是建议javaeye一下下），使用起来也非常的简单，它被用在了很多网站上面，几乎很少有大型的网站不会使用memcached。 


曾经我也看过很多剖析memcached内部机制的文章，有一点收获，但是看过之后又忘记了，而且没有什么深刻的概念，但是最近我遇到一个问题，这个问题迫使我重新来认识memcache，下面我阐述一下我遇到的问题 


问题：我有几千万的数据，这些数据会经常被用到，目前来看，它必须要放到memcached中，以保证访问速度，但是我的memcached中数据经常会有丢失，而业务需求是memcached中的数据是不能丢失的。我的数据丢失的时候，memcached server的内存才使用到60%，也就是还有40%内存被严重的浪费掉了。但不是所有的应用都是这样，其他应用内存浪费的就比较少。为什么内存才使用到60%的时候LRU就执行了呢（之所以确定是LRU执行是因为我发现我的数据丢失的总是前面放进去的，而且这个过程中，这些数据都没有被访问，比如第一次访问的时候，只能访问第1000w条，而第300w条或者之前的数据都已经丢失了，从日志里看，第300w条肯定是放进去了）。 


带着这些疑问，我开始重新审视memcached这个产品，首先从它的内存模型开始：我们知道c++里分配内存有两种方式，预先分配和动态分配，显然，预先分配内存会使程序比较快，但是它的缺点是不能有效利用内存，而动态分配可以有效利用内存，但是会使程序运行效率下降，memcached的内存分配就是基于以上原理，显然为了获得更快的速度，有时候我们不得不以空间换时间。 


也就是说memcached会预先分配内存，对了，memcached分配内存方式称之为allocator，首先，这里有3个概念： 
1 slab 
2 page 
3 chunk 
解释一下，一般来说一个memcahced进程会预先将自己划分为若干个slab，每个slab下又有若干个page，每个page下又有多个chunk，如果我们把这3个咚咚看作是object得话，这是两个一对多得关系。再一般来说，slab得数量是有限得，几个，十几个，或者几十个，这个跟进程配置得内存有关。而每个slab下得page默认情况是1m，也就是说如果一个slab占用100m得内存得话，那么默认情况下这个slab所拥有得page得个数就是100，而chunk就是我们得数据存放得最终地方。 


举一个例子，我启动一个memcached进程，占用内存100m，再打开telnet，telnet localhost 11211，连接上memcache之后，输入stats  slabs，回车，出现如下数据： 
Java代码  收藏代码
STAT 1:chunk_size 80  
STAT 1:chunks_per_page 13107  
STAT 1:total_pages 1  
STAT 1:total_chunks 13107  
STAT 1:used_chunks 13107  
STAT 1:free_chunks 0  
STAT 1:free_chunks_end 13107  
STAT 2:chunk_size 100  
STAT 2:chunks_per_page 10485  
STAT 2:total_pages 1  
STAT 2:total_chunks 10485  
STAT 2:used_chunks 10485  
STAT 2:free_chunks 0  
STAT 2:free_chunks_end 10485  
STAT 3:chunk_size 128  
STAT 3:chunks_per_page 8192  
STAT 3:total_pages 1  
STAT 3:total_chunks 8192  
STAT 3:used_chunks 8192  
STAT 3:free_chunks 0  
STAT 3:free_chunks_end 8192  




以上就是前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的一些健康情况，比如说命中率之类的，示例如下： 
Java代码  收藏代码
STAT pid 2232  
STAT uptime 1348  
STAT time 1218120955  
STAT version 1.2.1  
STAT pointer_size 32  
STAT curr_items 0  
STAT total_items 0  
STAT bytes 0  
STAT curr_connections 1  
STAT total_connections 3  
STAT connection_structures 2  
STAT cmd_get 0  
STAT cmd_set 0  
STAT get_hits 0  
STAT get_misses 0  
STAT bytes_read 26  
STAT bytes_written 16655  
STAT limit_maxbytes 104857600  


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


该到总结的时候了，从这篇文章里我们可以得到以下几个结论： 
结论一，memcached得LRU不是全局的，而是针对slab的，可以说是区域性的。 
结论二，要提高memcached的命中率，预估我们的value大小并且适当的调整内存页大小和增长因子是必须的。 

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

Memcached作为一个内存key-value存储容器有非常优秀的性能，但是在上次的使用中确发现大量的数据丢失情况发生，导致cache的功能基本消失。具体的检测方式如下：检测命中率

检测命中率是一个最基本的、最宏观的方式，使用telnet连接到memcached服务器，然后执行stats命令就可以看到宏观的一些信息

        这个命令中比较关键的属性是get_hits和get_misses，get_hits表示读取cache命中的次数，get_misses是读取失败的次数，即尝试读取不存在的缓存数据。
         命中率=get_hits / (get_hits + get_misses)
命中率越高说明cache起到的缓存作用越大。但是在实际使用中，这个命中率不是有效数据的命中率，有些时候get操作可能只是检查一个key存在不存在，这个时候miss也是正确的，这就像用memcached作为一种定时器，将一些临时数据在memcache中存放特定时间长度，业务逻辑会根据cache是否存在而作不同的逻辑，这种数据其实已经不是单纯的缓存了，也不应该统计到命中率中。再者，这个命中率是从memcached启动开始所有的请求的综合值，不能反映一个时间段内的情况，所以要排查memcached的性能问题，还需要更详细的数值。但是高的命中率还是能够反映出memcached良好的使用情况，突然下跌的命中率能够反映大量cache丢失的发生。

stats ：转储所连接的memcached 实例的当前统计数据。

flush_all：用于清理缓存中的所有名称/值对。如果您需要将缓存重置到干净的状态，则flush_all 能提供很大的用处。

查看memcached状态的基本命令，通过这个命令可以看到如下信息：

 

STAT pid 22459                             进程ID

STAT uptime 1027046                        服务器运行秒数

STAT time 1273043062                       服务器当前unix时间戳

STAT version 1.4.4                         服务器版本

STAT pointer_size 64                       操作系统字大小(这台服务器是64位的)

STAT rusage_user 0.040000                  进程累计用户时间

STAT rusage_system 0.260000                进程累计系统时间

STAT curr_connections 10                   当前打开连接数

STAT total_connections 82                  曾打开的连接总数

STAT connection_structures 13              服务器分配的连接结构数

STAT cmd_get 54                            执行get命令总数

STAT cmd_set 34                            执行set命令总数

STAT cmd_flush 3                           指向flush_all命令总数

STAT get_hits 9                            get命中次数

STAT get_misses 45                         get未命中次数

STAT delete_misses 5                       delete未命中次数

STAT delete_hits 1                         delete命中次数

STAT incr_misses 0                         incr未命中次数

STAT incr_hits 0                           incr命中次数

STAT decr_misses 0                         decr未命中次数

STAT decr_hits 0                           decr命中次数

STAT cas_misses 0    cas未命中次数

STAT cas_hits 0                            cas命中次数

STAT cas_badval 0                          使用擦拭次数

STAT auth_cmds 0

STAT auth_errors 0

STAT bytes_read 15785                      读取字节总数

STAT bytes_written 15222                   写入字节总数

STAT limit_maxbytes 1048576                分配的内存数（字节）

STAT accepting_conns 1                     目前接受的链接数

STAT listen_disabled_num 0                

STAT threads 4                             线程数

STAT conn_yields 0

STAT bytes 0                               存储item字节数

STAT curr_items 0                          item个数

STAT total_items 34                        item总数

STAT evictions 0                           为获取空间删除item的总数

 

Stats items

Stats items命令可以查看每个slab中存储的item的一些详细信息，具体可以见下图。

关键属性有：

最后被剔除的数据在cache中存放的时间，以秒为单位

stats items可以详细的观察各slab的数据对象的情况，因为memcached的内存分配策略导致一旦memcached的总内存达到了设置的最大内存，代表所有的slab能够使用的page都已经固定，这个时候如果还有数据放入，将开始导致memcached使用LRU策略剔除数据。而LRU策略不是针对所有的slabs，而是只针对新数据应该被放入的slab，例如有一个新的数据要被放入slab 3，则LRU只对slab 3进行。通过stats items就可以观察到这些剔除的情况。
具体分析如下：

evicted属性
如果一个slab的evicted属性不是0，则说明当前slab出现了提前剔除数据的情况，这个slab可能是你需要注意的。evicted_time属性
如果evicted不为0，则evicited_time就代表最后被剔除的数据时间缓存的时间。并不是发生了LRU就代码memcached负载过载了，因为有些时候在使用cache时会设置过期时间为0，这样缓存将被存放30天，如果内存慢了还持续放入数据，而这些为过期的数据很久没有被使用，则可能被剔除。需要注意的是，最后剔除的这个数据已经被缓存的时间，把evicted_time换算成标准时间看下是否已经达到了你可以接受的时间，例如：你认为数据被缓存了2天是你可以接受的，而最后被剔除的数据已经存放了3天以上，则可以认为这个slab的压力其实可以接受的；但是如果最后被剔除的数据只被缓存了20秒，不用考虑，这个slab已经负载过重了。age属性
age属性反应了当前还在缓存的数据中最久的时间，它的大小和evicted_time没有必然的大小关系，因为可能时间最久的数据确实频繁被读取的，这时候不会被LRU清理掉，但是如果它小于evicted_time的话，则说明数据在被下去读取前就被清理了，或者存放了很多长时间但是不被使用的缓存对象。Stats slabs

从Stats items中如果发现有异常的slab，则可以通过stats slabs查看下该slab是不是内存分配的确有问题。
Stats slabs结果如下图

Stats slabs的属性说明如下：

chunk_size	当前slab每个chunk的大小
chunk_per_page	每个page能够存放的chunk数
total_pages	分配给当前slab的page总数
total_chunks	当前slab最多能够存放的chunk数，应该等于chunck_per_page * total_page
used_chunks	已经被占用的chunks总数
free_chunks	过期数据空出的chunk里还没有被使用的chunk数
free_chunks_end	新分配的但是还没有被使用的chunk数

这个命令的信息量很大，所有属性都很有价值。下面一一解释各属性：

综合上面的数据，可以发现造成memcached的内存使用率降低的属性有：

chunk_size, chunk_per_page
这两个属性是固定的，但是它反映当前slab存储的数据大小，可以供你分析缓存数据的散列区间，通过调整增长因子可以改变slab的区间分布，从而改变数据散列到的区域。如果大量的230byte到260byte的数据，而刚好一个slab大小是250byte，则250byte到260byte的数据将被落到下一个slab，从而导致大量的空间浪费。total_pages
这个是当前slab总共分配大的page总数，如果没有修改page的默认大小的情况下，这个数值就是当前slab能够缓存的数据的总大小（单位为M）。如果这个slab的剔除非常严重，一定要注意这个slab的page数是不是太少了。
我上次处理的那个项目因为和另外的一个项目共用的memcache，而且memcache已经运行了很长时间，导致page都已经全部被分配完，而刚好两个项目的缓存数据大小差别很多，导致新项目数据最多的slab 4竟然只有一个page，所以数据缓存不到22s就被替换了，完全失去了缓存的意义。
针对我遇到的那个情况，解决方案是重新分配page，或者重启memcache服务。但是page reassign方法从1.2.8版已经完全移除了，所以现在没有办法在线情况下重新分配page了。另外一种有些时候是不可以接受的，因为一次缓存服务器的重启将导致所有缓存的数据将重新从DB取出，这个可能造成db的压力瞬间增大。而且有的缓存数据时不入库的，这个时候我们就需要做memcache的导入和导出了。在下篇文章中我会总结下memcache的dump操作。total_chunks
这个的作用和total_pages基本相同，不过这个属性可以更准确的反应实际可以存放的缓存对象总数。used_chunks, free_chunks, free_chunks_end
这三个属性相关度比较高，从数值上来看它们满足： 
                total_chunks = used_chunks + free_chunks + free_chunks_end
used_chunks就是字面的意思，已经使用的chunk数；free_chunks却不是所有的未被使用的chunk数，而是曾经被使用过但是因为过期而被回收的chunk数；free_chunks_end是page中从来没有被使用过的chunk数。


      从上图可以看出，slab 1只放了一个对象，但是已经申请了一整个page，这个时候used_chunks为1，但是free_chunks却为0，因为还没有任何回收的空间，而free_chunks_end却等于10081，说明这么多的chunk从来没有被使用过。下图就是这个数据过期后的stats slabs数据，可以发现free_chunks有值了，就是过期的那个chunk，所以是1，used_chunks为0，free_chunks_end不变。


      为什么要分两种free chunk呢？
      我的理解是这样的：如果free_chunks_end不为零，说明当前slab没有出现过容量不够的时候；而如果free_chunks始终为0，说明很多数据过期时间过长或者在过期前就被剔除了，这个要结合剔除数据和数据保留的时间（age属性）来看待。所以分开统计这两个值可以准确的判断实际空闲的chunk的状态，一旦所以的chunk被使用过一次以后，除非重新申请page，否则free_chunks_end始终为0。所以对于运行时间比较久的memcached，可能大部分这个值都是0。active_slabs, total_malloced
在stats slabs输出的最后两项是两个统计数据，一个是活动的slab总数，因为slab虽然带编号，但是这个编号不一定是连续的，因为有可能有些中间区间的slab没有值就没有初始化，这样以后该slab有值的时候就不用改变slab的编号了。所以活动的slab总数不一定等于slab的最大编号。
total_malloced这个是实际已经分配的总内存数，单位为byte，这个数值决定了memcached实际还能申请多少内存，如果这个值已经达到设定的上限，则不会有新的page被分配，以前分配的page也已经固定slab了。

 

    综合上面的数据，可以发现造成memcached的内存使用率降低的属性有：

page中从来没有被使用过的chunks；chunk中存放数据和chunk实际大小的差值；由于短时间的数据集中在某个slab区域，导致大量page被分配，而之后被闲置的内存，这些即使有整个page的空闲也不会被分配给实际压力很大的slab区域（这个功能是不是以后memcached会考虑实现呢？）。