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等概念
![](https://img-blog.csdn.net/20160607093229741?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
![](https://img-blog.csdn.net/20160607093242303)
- 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上,这是非常危险的操作。