从运维的角度理解memcached

Posted 虞大胆的叽叽喳喳

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从运维的角度理解memcached相关的知识,希望对你有一定的参考价值。

从应用的角度讲了讲memcached,这篇文章从运维的角色说一说,换个角度思考能够更好的使用memcached。

1:启动

memcached 在启动的时候有很多的参数,列举几个重要的。

-m:memcached 可以使用的内存,注意 memcached 实际占用的内存大于 -m 配置的值,比如网络连接也要占用内存。

-d:后台运行memcached。

-v:控制 STDOUT/STDERR 的输出,多个 -v 可以输出很多有用的数据,比如查看set了那些key,对于排查问题非常有用。

-p:修改 tcp 监听端口,对应的 udp 端口也修改。

-U:是否支持 udp 端口,默认是关闭的。

-u:以某个用户的身份启动 memcached,避免使用 root 启动,有效保障安全性。

-s:限制只有本地 user 通过 unix domain socket 访问。

-c:设置最大连接数,默认是 1024,如果当前最大连接数超过 -c 设置的值,请求在连接队列中等待,由于 memcached 连接占用的资源非常少,所以该值不要设置太高。

-t:工作线程数量,默认是 4,可以有效利用多核服务器,由于 memcached 性能很高,该值不建议设置过高。

2:硬件选择

从硬件角度调优系统参数。

(1)cpu or 内存

memcached 是多线程模型,性能极高,所以不一定要多核服务器,但内存越大越好。

那么选择什么样的服务器来放置 memcached 呢?如果规模较小,那么在 web 服务器上部署 memcached 是非常不错的选择,memcached cpu 消耗很小 ,不会加重 web 服务器的负载,而 web 服务器对内存的要求不高,剩下来的内存可以供 memcached 使用。

需要注意的是,不要在专用的数据库服务器上部署 memcached,因为这两个服务对内存的要求都非常高,避免发生 swap。

对于具有一定规模的业务来说,采用专门的服务器来部署 memcached 更有优势,它们都具有大容量的内存,需要注意的是,一个节点可以部署很多个实例,如果某个节点挂掉了,那么失效的 key 会非常多,这在容量规划的时候要注意。

(2)网卡

网络流量取决于memcached请求峰值和item平均大小,避免跑满带宽,不过现在的网卡都是千兆了,理论上应该不会出现问题。

(3)网络连接数

首先要注意的是,-c 启动的连接数不要太高,一方面避免超过系统允许的连接数;另外一方面memcached非常高效,没有必要设置太高,-c 最优化配置和操作系统本身的TCP优化很有关系。

memcached使用专门的一个线程接收客户端连接,如果客户端频繁的连接、释放,这个线程的压力会非常大,可以使用长连接或memcached udp 监听来避免连接和释放的消耗。

3:分析和监控

memcached 协议命令有两种类型,add/set/get主要用于完成工作,而其他一些内部命令对于排查、优化、分析都非常有帮助,比如:

  • stats:常规统计,列出的信息非常多。

  • stats slabs:slab 统计,返回大小和内存使用情况,也包含每个 slab class的统计信息。

  • stats item:item 统计,返回每个slab class 的item信息,相比 stats slabs 命令,stats items 显示更高层次的信息。

  • stats sizes:item 大小统计,返回不同大小item存储的个数。

了解这四个基本命令后,我们看看监控怎么弄,当然也可以看看官方提的一个工具:

https://github.com/memcached/memcached/blob/master/scripts/memcached-tool)。

并不是为了使用它,而是看看它关注什么,从中可以学到很多。

提醒:memcached 1.4版本以后,内部命令和内存管理发生了很大的变化,大家如果使用了一些外部统计和监控工具,需要看看这些工具有没有更新。

(1)应用监控,定时执行 set、get 等命令,监控操作是否成功,以及记录响应的性能。如果连接很慢,可能是网络问题,如果性能低下,可能产生了内存 swap。

(2)stats

curr_connections:查看某个端口的连接数,避免 curr_connections 大于配置的最大连接数(-c)。

listen_disabled_num:这个值最好接近于 0,如果大于0,表示有多个连接进入了连接队列,需要等待其他连接的释放。

accepting_conns:这个数值和 listen_disabled_num 很类似,如果服务连接数已达到最大值,该值被设置为 1。

limit_maxbytes:该值等于服务启动配置的内存总容量(-m),即有多少内存可以使用。

cmd_flush:该数值表示有多少个 flush 命令被执行了,如果数值过大,说明应用的模式有问题,从监控的角度看,应该尽量避免。

(3)查看 evicted

可以使用 stats 和 stats items 命令监控 evicted 和 evicted_nonzero 数量,前者针对整体,后者针对各个 slab。

evicted 表示被剔除的数量,evicted_nonzero 更重要,值如果过高表示没有过期的 item 被 evicted 的太多了,这可能会影响业务。

注意:evicted 过高,不一定代表内存不够。比如 set 了大量 keys,但这些 keys 后来从没使用过,也会导致 evicted 过高。

(4)查看命中率

通过 stats 命令可以统计全局的命中率:get_hits / (get_hits + get_misses,了解某个时间点命中率,以及命中率变化的情况。

stats slabs 命令能够了解每个 slab 的统计情况,但没有 get_misses 数值,但可以通过观察 get_hits 和 cmd_set 间接了解每个 slab 命中率的变化。

注意:命中率不高,不一定代表内存不够,比如请求的 keys 大量不存在,也会导致命中率过低。

(5)系统监控

比如系统负载,cpu 使用率、swap 情况、网卡流量等等。

memcached 相关文章:

  •  

  •  


以上是关于从运维的角度理解memcached的主要内容,如果未能解决你的问题,请参考以下文章

分布式存储运维的 11 个难点 | 运维进阶

带给你不一样的运维思考

从运维角度看中大型网站架构的演变之路

从运维角度看 JAVA 技术

Linux从运维到DevOps

从运维角度浅谈MySQL数据库优化