《正确理解memcached,才能更好的使用》从应用的角度讲了讲memcached,这篇文章从运维的角色说一说,换个角度思考能够更好的使用memcached。
1:启动
memcached 在启动的时候有很多的参数,列举几个重要的。
-m:表示 memcached 可以使用的内存,注意 memcached 实际占用的内存大于 -m 配置的值,比如网络连接也要占用内存。
-d:表示在后台运行memcached。
-v:控制 STDOUT/STDERR 的输出,多个 -v 可以输出很多有用的数据,比如查看set了那些key,对于排查问题非常有用。
-l:表示服务绑定的网卡地址,绑定内网网卡可以有效保证安全性。
-p:修改 tcp 监听端口,对应的 udp 端口也修改。
-U:是否支持 udp 端口,默认是关闭的。
-u:以某个用户的身份启动 memcached,避免使用 root 启动,有效保障安全性。
-s:严格限制只有本地 user 通过 unix domain socket 访问memcached。
-c:设置最大连接数,默认是 1024,如果当前最大连接数超过 -c 设置的值,请求在连接队列中等待,由于 memcached 连接占用的资源非常少,所以该值不要设置太高。
-t:工作线程数量,默认是 4,可以有效利用多核服务器,由于 memcached 性能很高,该值不建议设置过高。
2:硬件
从硬件的角度思考 memcached,以便选择正确的硬件,对某个系统参数进行调优。
(1)cpu or 内存
memcached 是多线程模型,性能极高,所以不一定要多核服务器,但内存越大越好。
那么选择什么样的服务器来放置 memcached 呢?如果规模较小,那么在 web 服务器上部署 memcached 是非常不错的选择,memcached cpu 消耗很小 ,不会加重 web 服务器的负载,而 web 服务器对内存的要求不高,剩下来的内存可以供 memcached 使用。
需要注意的是,不要在专用的数据库服务器上部署 memcached,因为这两个服务对内存的要求都非常高,避免发生 swap。
对于具有一定规模的业务来说,采用专门的服务器来部署 memcached 更有优势,它们都具有大容量的内存,需要注意的是,一个节点可以部署很多个实例,如果某个节点挂掉了,那么失效的 key 会非常多,这在容量规划的时候要注意。
(2)网卡
网络流量取决于memcached请求峰值和item平均大小,避免跑满带宽,不过现在的网卡都是千兆了,理论上应该不会出现问题。
(3)网络连接数
首先要注意的是,-c 启动的连接数不要太高,避免超过系统可用的连接数,也有可能出现太多的 TIME_WAIT,另外 memcached 本身性能极高,所以没有太大的必要配置过高的连接数。
memcached使用专门的线程接收客户端连接,所以一定要避免连接数过高,否则可能会影响服务,从减少连接数的角度看,可以使用长连接或memcached udp 监听。
3:监控
(1)应用监控,定时执行 set、get 等命令,监控操作是否成功,以及记录响应的性能。如果连接很慢,可能是网络问题,如果性能低下,可能产生了内存 swap。
(2)重要的 stat 命令
curr_connections:查看某个端口的连接数,避免 curr_connections 大于配置的最大连接数(-c)。
listen_disabled_num:这个值最好接近于 0,如果大于0,表示有多个连接进入了连接队列,需要等待其他连接的释放。
accepting_conns:这个数值和 listen_disabled_num 很类似,如果服务连接数已达到最大值,该值被设置为 1。
limit_maxbytes:该值等于服务启动配置的内存总容量(-m),即有多少内存可以使用。
cmd_flush:该数值表示有多少个 flush 命令被执行了,如果数值过大,说明应用的模式有问题,从监控的角度看,应该尽量避免。
stat sizes:可以详细浏览不同 slab page 的使用情况,以便更好使用 memcached,需要注意的是,如果 memcached 版本过低,运行该命令会扫描所有 item,比较危险。
(3)观察 slab
可以使用 stat 和 stats items 命令监控 evicted 和 evicted_nonzero 数量,前者针对整体,后者针对 slab 局部。evicted 表示被剔除的数量,evicted_nonzero 更重要,值如果过高表示没有过期的 item 被 evicted 的太多了,这可能会影响业务。
如果 slabs 的 evictions 很高,且 do not line up with the pages very well,需要启动服务重新分配内存,不过更高版本的 memcached,可以不重启服务,可以自动调整 slab 和内存。
(4)应用分析
从应用的角度审视 memcached 使用情况,主要是为了了解 memcached 中可使用内存,以及使用效率。
全局的命中率:get_hits / (get_hits + get_misses,了解某个时间点命中率,以及命中率变化的情况。
stats slabs 能够了解每个 slab 的统计情况,但没有 get_misses 数值,但可以通过观察 get_hits 和 cmd_set 间接了解每个 slab 命中率的变化。
evicted_time,如果该值很小,表示最近有 item 正在被 evicted。
一个误区:如果命中率不高,不一定代表内存不够,如果 evicted 过高,不一定代表内存不够。比如应用程序 set 了大量 keys,但这些 keys 后来从没使用过,会导致 evicted 过高;再比如请求的 keys 大量不存在,也会导致命中率过低。
(5)硬件监控
主要监控 cpu 使用率、swap 情况、网卡流量等常规数据。
以上所述就是小编给大家介绍的《从运维的角度理解memcached》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 从人类行为的角度理解状态管理
- 从运维的角度理解 memcached
- 从源码角度深入理解Glide(下)
- 从工程的角度,重新理解 Python
- 以“一个公式” 的角度理解原型链
- 从 Vue 源码角度来理解虚拟 DOM
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。