Memcache 优化建议

以你之姓@ 2022-08-07 09:44 279阅读 0赞

**一、memcached工作原理**

基本概念：slab，page，chunk。  
**slab**，是一个逻辑概念。它是在启动memcached实例的时候预处理好的，每个slab对应一个chunk size，也就是说不同slab有不同的chunk size。具体分配多少个slab由参数 -f （增长因子）和 -n （chunk最小尺寸）决定的。  
**page**，可以理解为内存页。大小固定为1m。slab会在存储请求时向系统申请page，并将page按chunk size进行切割。  
**chunk**，是保存用户数据的最小单位。用户数据item（包括key，value）最终会保存到chunk内。chunk规格是固定的，如果用户数据放进来后还有剩余则这剩余部分不能做其他用途。  
**二、memcached工作流程**

memcahed实例启动，根据 -f 和 -n 进行预分配slab。以 -n 为最小值开始，以 -f 为比值生成等比数列，直到1m为止（每个slab的chunk size都要按8的倍数进行补全，比如：如果按比值算是556的话，会再加4到560成为8的整倍数）。然后每个slab分配一个page。当用户发来存储请求时（key,value），memcached会计算key+value的大小，看看属于哪个slab。确定slab后看里面的是否有空闲chunk放key+value，如果不够就再向系统申请一个page（如果此时已经达到 -m 参数设置的内存使用上限，则看是否设置了 -M 。如果设置了 -M 则返回错误提示，否则按LRU算法删除数据）。申请后将该page按本slab的chunk size 进行切割，然后分配一个来存放用户数据。  
注意：  
1，chunk是在page里面划分的，而page固定为1m，所以chunk最大不能超过1m。  
2，chunk实际占用内存要加48B，因为chunk数据结构本身需要占用48B。  
3，如果用户数据大于1m，则memcached会将其切割，放到多个chunk内。  
4，已分配出去的page不能回收。  
**三、优化建议**  
1，-n 参数的设置，注意将此参数设置为1024可以整除的数（还要考虑48B的差值），否则余下来的部分就浪费了。  
2，不要存储超过1m的数据。因为要拆成多个chunk，计算和时间成本都成倍增加。  
3，善用stats命令查看memcached状态。  
4，消灭eviction（被删除的数据）。造成eviction是因为内存不够，有三个思路：

一是在CPU有余力的情况下开启压缩（PHP扩展）；

二是增加内存；

三是调整-f参数，减少内存浪费。  
5，调整业务代码，提高命中率。  
6，缓存小数据。省带宽，省网络I/O时间，省内存。  
7，根据业务特点，为数据尺寸区间小的业务分配专用的memcached实例。这样可以调小 -f 参数，使数据集中存在少数几个slab上，内存浪费较少。

转至：[http://blog.csdn.net/nyist327/article/details/44462151][http_blog.csdn.net_nyist327_article_details_44462151]

**四、其他性能建议及优化手段**  
性能的调整只能给出一般性的原则，实际情况千差万别，每次调整都需要做实际的测量才能确定是否带来期望的效果。  
1、连接池设置  
在高负载环境下，nio的单连接也会遇到瓶颈，此时你可以通过设置连接池来让更多的连接分担memcached的请求负载，从而提高系统的吞吐量。连接池通常不建议设置太大，我推荐在0-30之间为好，太大则浪费系统资源，太小无法达到分担负载的目的。  
2、如果你的数据较小，如在1K以下，默认的配置选项已经足够。如果你的数据较大，我会推荐你调整网络层的TCP选项，如设置socket的接收和发送缓冲区更大，启用Nagle算法等等：     
builder.setSocketOption(StandardSocketOption.SO\_RCVBUF, 32\* 1024);// 设置接收缓存区为32K，默认16K  
builder.setSocketOption(StandardSocketOption.SO\_SNDBUF,16 \*1024); // 设置发送缓冲区为16K，默认为8K  
builder.setSocketOption(StandardSocketOption.TCP\_NODELAY,false); // 启用nagle算法，提高吞吐量，默认关闭  
默认如果连接超过5秒没有任何IO操作发生即认为空闲并发起心跳检测，你可以调长这个时间：    
builder.getConfiguration().setSessionIdleTimeout(10000); // 设置为10秒;  
更多网络层配置选项请参见Configuration类。  
  
3、Xmemcached默认会做两个优化：将连续的单个get合并成一个multi get批量操作获取，将连续的请求合并成socket发送缓冲区大小的buffer发送。  
如果你对响应时间比较在意，那么可以将合并的因子减小，或者关闭合并buffer的优化：  
memcachedClient.setMergeFactor(50);  //默认是150，缩小到50  
memcachedClient.setOptimizeMergeBuffer(false); //关闭合并buffer的优化  
如果你对吞吐量更在意，那么也可将合并因子调大，默认是150。但是也不可太大，太大可能导致平均响应时间延长。  
  
4、如果你对心跳检测不在意，也可以关闭心跳检测，减小系统开销  
memcachedClient.setEnableHeartBeat(false);  
这个关闭，仅仅是关闭了心跳的功能，客户端仍然会去统计连接是否空闲，禁止统计可以通过：  
builder.getConfiguration().setStatisticsServer(false);  
  
5.TimeoutException处理  
由于xmemcached的通讯层是基于非阻塞IO的，那么在请求发送给memcached之后，需要等待应答的到来，这个等待时间默认是1秒，如果超过1秒就抛出java.util.TimeoutExpcetion给用户。如果你频繁抛出此异常，可以尝试将全局的等待时间设置长一些，如我在压测中 设置为5秒：  
memcachedClient.setOpTimeout(5000L);    
请注意，setOpTimeout设置的是全局的等待时间，如果你仅仅是希望将get或者set等操作的超时延长一点，那么可以通过这些方法的重载方法来 使用：  
<T> T get(java.lang.String key,long timeout)  
boolean set(java.lang.String key, int exp,java.lang.Object value,long timeout)

**五、使用注意事项**  
1.Memcached的Key，要杜绝使用空格，且长度控制在250个字符。  
2.Memcached的Value，要控制体积，必须小于1MB，必要时进行使用压缩。  
3.失效时间，0为永久有效，最大值不得超过30天（2592000s），否则重新计算可能缓存只有1秒  
4.Memcached仅支持LRU算法，完全适用你的需要。  
5.尽量不要将List这种重体积对象扔到Memcached中，传输、存储都会产生瓶颈。  
6.使用一致性哈希算法实现，提高多个Memcacehd Server利用率。  
7.关于SET&ADD  
\* SET&ADD都属于更新操作，都要先申请内存  
\* SET，会擦除这个键所对应的内存，不管原先是否有内容  
\* ADD，会先查看这个键对应的内存是否有内容，如果有，则等待；若没有，则获取锁，并更新内存。  
  
**启动时最重要的参数**：  
\-m  整个memcached最大内存  
\-f  chunk大小增长因子  
\-n  chunk最小分配空间  
\-C  禁用CAS  
\-vvv 打印详细信息  
我们通过计算可以看出，每个slab的chunk size大小都是上一个大小的1.25倍，1.25就是memcached启动时制定的-f的值，所以，要根据不同的业务场景调整，既要尽可能少的减少内存浪费，又要存得下我们业务中的数据，再举个例子，加入我们的业务很BT，大小都是200kb，我们该怎么做？那当然是要保证我们申请的chunk大小都是200kb了，虽然memcached并不支持这么做。假如创建了38个slabs，最后数据全都落到了第20-25个slab中，那0-19和26-38的内存就被浪费了，这只是能评估出来的，还有一种情况，加入我们的chunk大小是500kb，数据才200kb，因为每个chunk都只能存储一个，所以一个chunk就会有500kb-200kb的空间浪费，如果有一千万个chunk要存，那将会浪费多少空间？所以，在使用memcached之前，先要评估你的数据，根据它去调整-f因子。

在应对高并发攻击处理，可以限制访问，请参考：[http://snowolf.iteye.com/blog/1576818][http_snowolf.iteye.com_blog_1576818]

[http_blog.csdn.net_nyist327_article_details_44462151]: http://blog.csdn.net/nyist327/article/details/44462151
[http_snowolf.iteye.com_blog_1576818]: http://snowolf.iteye.com/blog/1576818