memcached 一些知识

1 相关操作

启动：memcached -d -m 512 -u root -l 10.210.227.78 -p 13000 -c 512

telnet 操作

stats 查看状态

2 memcached stats 命令说明

• pid: memcached服务进程的进程ID
• uptime: memcached服务从启动到当前所经过的时间，单位是秒。
• time: memcached服务器所在主机当前系统的时间，单位是秒。
• version: memcached组件的版本。
• libevent: libevent版本号   linux服务器会有这个属性
• pointer_size：服务器所在主机操作系统的指针大小，一般为32或64.
• rusage_user :进程累积用户时间（Linux）
• rusage_system:进程累积系统时间
• curr_connections：表示当前系统打开的连接数。
• total_connections：表示从memcached服务启动到当前时间，系统打开过的连接的总数
• connection_structures：表示从memcached服务启动到当前时间，被服务器分配的连接结构的数量
• cmd_get：get命令总请求次数
• cmd_set：set 命令总请求次数
• get_hits：表示获取数据成功（命中）的次数，依据此数据可以计算出缓存命中率
• get_misses：表示获取数据失败的次数。
• delete_misses：   delete命令未命中次数
  
• delete_hits：  delete 命中次数
• incr_misses：incr命令未命中次数
• incr_hits：incr命令命中次数
• decr_misses：decr命令未命中次数
• decr_hits：decr命令命中次数
• cas_misses：cas命令未命中次数
• cas_hits：cas命令命中次数
• cas_badval：使用擦拭次数
  
• auth_cmds：认证命令处理的次数
  
• auth_errors: 认证失败的次数
  
• bytes_read：memcached服务器从网络读取的总的字节数。
  
• bytes_written：memcached服务器发送到网络的总的字节数。
  
• limit_maxbytes：memcached服务缓存允许使用的最大字节数。即启动时设定的空间
  
• accepting_conns :服务器是否达到过最大连接
  
• listen_disabled_num：失效的监听数
  
• threads：当前线程数
  
• conn_yields ：连接操作主动放弃数目
  
• bytes：当前存储占用的字节数
  
• curr_items： 当前存储的数据总数
  
• total_items： 启动以来存储的数据总数
• evicv：被剔除的数据items 数。依次可计算剔除率
• reclaimed ：已过期的数据条目来存储新数据的数目
  

3 Memcached 内存管理

    mc 的内存管理中  有 page  slab  chunk等概念

• slab  一个虚拟的概念 一个等级  mc  将内存划分为若干个slab等级，每个等级储存固定大小的对象。比如slab1 储存96bytes的对象，所有小于96bytes的对象都存储在slab1中
• chunk  一个真实的存储概念，对象实际存放在chunk中，chunk的大小与Slab等级对应，每个slab等级中的chunk都是相同大小的。如 slab1中的chunk都是96bytes。slab会根据自身的大小将page大小的内存分割成 page / slabsize 个chunk。
• page  mc内存分配的大小。默认一个page为1MB  是memcached在收到内存不够的请求，并进行内存分配的单位。举例来说，slab2的所有空间都用完了，又有大小适合slab2的数据过来了，那么slab2就会向memcached请求新的内存空间，memcached就会划分一个page大小的内存量到slab2。

   

如下图所示  每个slab class  的后两列相乘结果差不多大小 为1MB空间 也就是一个page的大小，相邻class的chunk大小相差1.25倍

可以在启动时加上参数-vv 显示内存的分配过程

     

 4 查看Slab分配情况

通过 stats  slabs 可以查看当前slabs的分配情况，下图是一个刚启动的mc服务的slabs

可以看到并没有分配任何空间，当执行两次set操作以后再查看

 

这就说明mc并不是预先分配好空间，而是需要的时候再分配。对于一些使用mc来抗数据库压力的使用场景，热缓存是非常重要的一个过程，否则在开始的一段时间，mc里面几乎没有数据，也没有分配内存，所有的请求依然会穿透到DB上，这是非常危险的操作。