技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> PHP --> Memcached数据被踢(evictions>0)现象分析

Memcached数据被踢(evictions>0)现象分析

浏览:2126次  出处信息

    很多同学可能熟知Memcached的LRU淘汰算法,它是在slab内部进行的,如果所有空间都被slabs分配,即使另外一个slab里面有空位,仍然存在踢数据可能。你可以把slab理解为教室,如果你的教室满了,即使别的教室有空位你的教室也只能踢人才能进人。

    mc

    本文介绍的却是另外一种现象。今天监控发现线上一memcached发生数据被踢现象,用stats命令看evictions>0,因为以前也出现过此问题,后来对这个参数增加了一个监控,所以这次主动就发现了。由于给memcached分配的内存远大于业务存储数据所需内存,因此初步判断是“灵异现象”。

    第一步,netstat查看所有连接,排除是否被一些未规划的client使用,经排查后断定无此可能。

    第二步,用tcpdump抽样检查set的指令,排除是否有忘记设cache过期时间的client,初步检查所有典型的业务都有expire time。

    第三步,Google,未果

    第四步,看源代码,了解evictions计数器增加时的具体细节,oh, no…

    in items.c, memcached-1.2.8,    

以下是代码片段:

         for (search = tails[id]; tries > 0 && search != NULL; tries--, search=search->prev) {
             if (search->refcount == 0) {
                 if (search->exptime == 0 || search->exptime > current_time) {
                     itemstats[id].evicted++;
                     itemstats[id].evicted_time = current_time - search->time;
                     STATS_LOCK();
                     stats.evictions++;
                     STATS_UNLOCK();
                 }
                 do_item_unlink(search);
                 break;
             }
         }

    从源代码发现踢数据只判断一个条件,if (search->refcount == 0),这个refcount是多线程版本计数用,在当前服务器未启用多线程情况下,refcount应该始终为0,因此初步判断memcached是从访问队列尾部直接踢数据。

    为了证实想法,设计以下场景:

部署一个memcached测试环境,分配比较小的内存,比如8M设置1条永远不过期的数据到memcached中,然后再get一次,这条数据后续应该存在LRU队尾。每隔1S向memcached set(并get一次) 1,000条数据,过期时间设为3秒。一段时间后,stats命令显示evictions=1

    按我以前的理解,第2步的数据是永远不会被踢的,因为有足够过期的数据空间可以给新来的数据用,LRU淘汰算法应该跳过没过期的数据,但结果证实这种判断是错误的。以上业务的服务器发生被踢的现象是由于保存了大量存活期短的key/value,且key是不重复的。另外又有一业务保存了小量不过期的数据,因此导致不过期的数据惨遭被挤到队列踢出。

    本来这个问题就告一段落了,但在写完这篇文章后,顺便又看了新一代memcached 1.4.1的源代码,很惊喜发现以下代码被增加。

    items.c, memcached 1.4.1

以下是代码片段:
     /* do a quick check if we have any expired items in the tail.. */
     int tries = 50;
     item *search;
     for (search = tails[id];
          tries > 0 && search != NULL;
          tries--, search=search->prev) {
         if (search->refcount == 0 &&
             (search->exptime != 0 && search->exptime < current_time)) {
             it = search;
             /* I don’t want to actually free the object, just steal
              * the item to avoid to grab the slab mutex twice 
              */
             it->refcount = 1;
             do_item_unlink(it);
             /* Initialize the item block: */
             it->slabs_clsid = 0;
             it->refcount = 0;
             break;
         }
     }

    重复进行上述测试,未发生evictions。

    9/8 Update: 注意到L108的tries=50没有?试想把测试第2步设置51条不过期数据到cache中,情况会怎样?因此新版的Memcached也同样存在本文描述问题。

    几条总结:

  • 过期的数据如果没被显式调用get,则也要占用空间。     
  • 过期的不要和不过期的数据存在一起,否则不过期的可能被踢。     
  • 从节约内存的角度考虑,即使数据会过期,也不要轻易使用随机字符串作为key,尽量使用定值如uid,这样占用空间的大小相对固定。     
  • 估算空间大小时候请用slab size计算,不要按value长度去计算。     
  • 不要把cache当作更快的key value store来用, cache不是storage。
  • 建议继续学习:

    1. 分布式缓存系统 Memcached 入门    (阅读:14725)
    2. 30分钟3300%性能提升――python+memcached网页优化小记    (阅读:12134)
    3. Cacti 添加 Memcached 监控    (阅读:8118)
    4. Redis和Memcached的区别    (阅读:6781)
    5. 启用memcached压缩注意事项    (阅读:4081)
    6. Memcached内存管理机制浅析    (阅读:4008)
    7. memcached 源码阅读笔记    (阅读:3670)
    8. Memcached and MySQL    (阅读:3261)
    9. Memcached的线程模型及状态机    (阅读:3267)
    10. Memcached二三事儿    (阅读:3137)
    QQ技术交流群:445447336,欢迎加入!
    扫一扫订阅我的微信号:IT技术博客大学习
    © 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

    京ICP备15002552号-1