使用Memcached的8个要点
内存使用:
1.Memcached数据由slabs组成,slabs由pages组成,pages由chunks组成
大对象分一组,小对象分一组,分别存在不同的Memcached服务器上,这样优化可以尽可能地使用好内存。
2.键和值都占用内存,所以使用短的键名称可以节省空间
3.当内存满的时候,系统使用LRU(Least Recently Used)算法进行内存管理
你在使用过程中可能碰到以下问题:
1.如果连接服务器滞后,那么你可能达到最大连接数限制
2.如果处理命令滞后,有可能碰到一些问题,通常是硬件问题,没有足够的RAM来做内存交换,网络问题(带宽,丢包,半双工连接等),极少情况下可能是操作系统或者memcached本身的bug导致的。另外连接问题通常是防火墙设置问题。
3.请确保服务的时间是正确的,因为Memcached的超时设置是相对于服务器时间的,另外设置超时时间请精确到秒
理论限制:
1.你的客户端连接数是有限制的
2.在一个集群中的节点数量也是有限制的
A.从客户角度
大量的服务器可以从几个角度放缓的客户端。如果你正在计算在每次请求的服务器哈希表,当你添加服务器将放缓。大多数客户将计算表一次启动和重新使用它请求之间。
查找一个服务器发出一个请求是一个简单的哈希查找,所以它不是一个性能问题。
•从客户端废物RAM建立太多的TCP套接字
•禁用持久连接是指客户端可能会连接到所有服务器上的每个请求。 3次握手会增加延迟和数据包到每个请求。
B.Multiget洞
曾经有一个Facebook的笔记提的是,当你将服务器添加到集群中的讨论,更分散multigets的。如果您发出multiget要求10键针对2服务器集群,将转成两个系统调用;每个服务器一个。如果你有10台服务器,你最终会与每个服务器都有一个系统调用。本身做得更多的系统调用的服务器,以配合较小的传入请求,以及它们的容量下降。
这不是一个不可逾越的问题。它可能与许多客户将相关键一起。针对特定用户的配置文件的所有密钥最终会在相同的memcached实例,因此一个multiget将达到一个单一的服务器与所有其键并使用少得多的系统调用。
C.一个精心设计的二进制协议客户端
使用spymemcached作为一个例子;客户端可以采取许多应用程序线程,并使用单个TCP连接返回memcached。与二进制协议,它是可能的包装从不同的客户端的实例的请求到相同的TCP套接字,然后返回结果到正确的所有者。
这意味着一个应用服务器,在理论上可以只要求每台memcached的实例中的一个的TCP套接字。如果每个应用程序节点运行50个线程或进程,这可以极大地从大减少安装的开销。
D.记得摩尔定律
如果许多大型网站都使用相同的硬件,他们曾在2007年为新memcached的情况下,它们可以具有4倍以上的服务器计数比现在。随着时间的流逝内存变便宜,网络容量的增加。硬件的增加并不一定会留在你的成长曲线的后面,但他们承担着巨大的脱离,你可以在理论上减半服务器计算每隔几年。
E.经济规模
我将简要地指出,大规模的装置吸引更好的人才。的现实情况是更可能涉及领域的专家,如果你的流量是巨大的。该集群越大,您遇到的问题的怪异,就越有可能你是有一队人参与维护它。这些都是极端情况下的需要保证性能非常大的集群。大多数用户都会有偶尔的问题需要克服,但不足以保证员工。
参考:
Memcached启动参数:
http://linux.die.net/man/1/memcached
Memcached内存分配和优化
http://returnfoo.com/2012/02/memcached-memory-allocation-and-optimization-2/
Memcached监控工具:http://code.google.com/p/phpmemcacheadmin/
Memcached是如何工作的?
http://www.linuxjournal.com/article/7451?page=0,1
Memcached如何编程?
http://code.google.com/p/memcached/wiki/NewProgramming
关于Memcached的性能
http://code.google.com/p/memcached/wiki/NewPerformance
Memcached使用大量小对象有何影响?
http://dom.as/2008/12/25/memcached-for-small-objects/
优化Memcached:
https://www.reviewboard.org/docs/manual/2.0/admin/optimization/memcached/
Php Memcached优化讨论:
https://groups.drupal.org/node/306033