1. 现在的memcached规格中,键长度最大为250字节,但二进制协议中键的大小用2字节表示。因此,理论上最大可使用65536字节(216)长的键。尽管250字节以上的键并不会太常用,二进制协议发布之后就可以使用巨大的键了。
二进制协议从下一版本1.3系列开始支持
2. memcached默认采用slab allocation机制分配、整理内存,其基本原理是按照预先规定的大小,将分配的内存分割成特定长度的块(chunk),以完全解决内存碎片问题。
2.5 slab allocation术语介绍
page:分配给slab的内存空间,默认是1M。分配给Slab后根据slab的大小切分成chunk。
chunk:用于缓存记录的内存空间。
slab class:特定大小的chunk组
3. slab allocation可以重复使用已分配的内存,分配到的内存不会释放,而是重复利用。
4. slab allocation的缺点是由于分配的是特定长度的内存,因此无法有效利用分配的内存,将100字节的数据缓存到128字节的chunk中,就有28字节浪费了。
比较好的调优方案是计算预先客户端的数据大小,采用合适的chunk大小分组
5. chunk大小分组的方法:memcached -f 2,其中-f是growth Factor因子,默认为1.25,曾经为2,即每个chunk划分的大小是前一个chunk大小的f倍。
按照计算的数据预期长度来调节growth factor值
6. 连接上memcached(可以用telnet连接),输入stats可以查看memcached状态,stats slabs或者stats items可以获得关于缓存的信息,quit退出。
7. 关于memcached分布式
7.1 根据余数进行打散:mc key的hash值(crc32等)/服务器台数,无法连接时将连接次数添加到key后面,rehash后再连接
余数打散法优点:方法简单,数据分散性也很优秀。
缺点:当添加/移除服务器时,缓存重组的代价相当巨大,缓存命中率明显下降。
7.2 mixi采用的Consistent Hashing分布法:首先求出memcached服务器(节点)的hash值,并将其配置到0~2的32次方的圆上,然后用同样的方法求出mc key的hash值,并映射到圆上。然后从数据映射的位置开始顺时针查找,将数据保存到找到的第一个服务器上。如果超过2的32次方仍然找不到服务器,就 会保存到第一台memcached服务器上。
优点:当添加服务器时,只有这台服务器添加位置的逆时针方向的第一台服务器上的key会受到影响,最大程序抑制了key的重新分布。
*而且,有的Consistent Hashing实现方法还采用了虚拟节点的思想。使用一般hash函数的话,服务器的映射地点非常不均匀。因此,使用虚拟节点的思想,为每个服务器在圆上 虚拟分配100~200个点。这样就能抑制分布不均匀,最大限度减少服务器增减时的缓存重新分布。
8. last.fm开发了一个支持Consistent Hashing的PHP库,名为ketama
9. memcached进程的实际内存分配量要比指定的容量要大,因为启动指定的只是用于数据保存的内存大小,并不包括slab allocation本身占用的内存以及为保存数据而设置的管理空间等。
10. memcached内存分配量尽量不要超过3G(即使是64位的4G内存的服务器),因有可能造成内存交换(swap)
11. 将与memcache的连接保持在进程中,以减少TCP连接的开销。
12. 如果不支持连接失败的rehash功能,则最好限制连接失败后指定时间内不要再连接该失败的服务器。
13. 将所有共享/公用的缓存数据设置类命名空间,将该命名空间下的key保存到多台memcached服务器中,取得时从中仅选取一台即可。
14. daemontools可以监视memcached进程的停止并自动启动。
15. nagios监视memcached的get、add动作,也可以监视stats
16. rrdtool将stats目录转化成图形,进行性能监视