一、Memcache内存分配机制

关于这个机制网上有很多解释的,我个人的总结如下。

Page为内存分配的最小单位。

Memcached 的内存分配以page为单位,默认情况下一个page是1M,可以通过-I参数在启动时指定。如果需要申请内存 时,memcached会划分出一个新的page并分配给需要的slab区域。page一旦被分配在重启前不会被回收或者重新分配(page ressign已经从1.2.8版移除了)

Slabs划分数据空间。

Memcached
并不是将所有大小的数据都放在一起的,而是预先将数据空间划分为一系列slabs,每个slab只负责一定范围内的数据存储。如
下图,每个slab只存储大于其上一个slab的size并小于或者等于自己最大size的数据。例如:slab 3只存储大小介于137 到 224
bytes的数据。如果一个数据大小为230byte将被分配到slab
4中。从下图可以看出,每个slab负责的空间其实是不等的,memcached默认情况下下一个slab的最大值为前一个的1.25倍,这个可以通过修
改-f参数来修改增长比例。

Chunk才是存放缓存数据的单位。

Chunk
是一系列固定的内存空间,这个大小就是管理它的slab的最大存放大小。例如:slab 1的所有chunk都是104byte,而slab
4的所有chunk都是280byte。chunk是memcached实际存放缓存数据的地方,因为chunk的大小固定为slab能够存放的最大值,

所以所有分配给当前slab的数据都可以被chunk存下。如果时间的数据大小小于chunk的大小,空余的空间将会被闲置,这个是为了防止内存碎片而设
计的。例如下图,chunk size是224byte,而存储的数据只有200byte,剩下的24byte将被闲置。

Slab的内存分配。

Memcached在启动时通过-m指定最大使用内存,但是这个不会一启动就占用,是随着需要逐步分配给各slab的。
  
     
如果一个新的缓存数据要被存放,memcached首先选择一个合适的slab,然后查看该slab是否还有空闲的chunk,如果有则直接存放进去;如

果没有则要进行申请。slab申请内存时以page为单位,所以在放入第一个数据,无论大小为多少,都会有1M大小的page被分配给该slab。申请到

page后,slab会将这个page的内存按chunk的大小进行切分,这样就变成了一个chunk的数组,在从这个chunk数组中选择一个用于存储
数据。如下图,slab 1和slab 2都分配了一个page,并按各自的大小切分成chunk数组。

Memcached内存分配策略。

综合上面的介绍,memcached的内存分配策略就是:按slab需求分配page,各slab按需使用chunk存储。
这里有几个特点要注意,

Memcached分配出去的page不会被回收或者重新分配Memcached申请的内存不会被释放slab空闲的chunk不会借给任何其他slab使用

知道了这些以后,就可以理解为什么总内存没有被全部占用的情况下,memcached却出现了丢失缓存数据的问题了。

众所周知,memcache采用slab allocator管理内存,启动由-m指定可用的最大内存值(默认64M),默认是使用时再分配,-k可提前分配内存并锁定;
每个slab包含若干大小为1M的内存页,这些内存又被分割成多个chunk,每个chunk存储一个item;
在mc启动初始化时,每个slab都预分配一个1M的内存页,由slabs_preallocate 完成(也可将相应代码注释掉关闭预分配功能);
chunk的增长因子由-f指定,默认1.25,起始大小为48字节;

item
为实际存储数据的结构体,由两部分组成,属性信息和数据部分,数据部分包括cas,key和真实的value信息。
  • typedef struct _stritem {
  • struct _stritem *next;//item在slab中存储时,是以双链表的形式存储的,next即后向指针
  • struct _stritem *prev;//prev为前向指针
  • struct _stritem *h_next;//Hash桶中元素的链接指针
  • rel_time_t      time; //最近访问时间
  • rel_time_t      exptime;//过期时间
  • int             nbytes;//数据大小
  • unsigned short  refcount;//引用次数
  • uint8_t         nsuffix;
  • uint8_t         it_flags;
  • uint8_t         slabs_clsid;//标记item属于哪个slabclass下
  • uint8_t         nkey;       //key的长度
  • union {
  • uint64_t cas;
  • char end;
  • } data[];//真实的数据信息
  • } item;
slab
何时分配新的slab? 1 bigger item; 2 no free chunk;
If the new item is bigger than the size
of any existing blocks, then a new slab is created, divided up into
blocks of a suitable size. If an existing slab with the right block size
already exists, but there are no free blocks, a new slab is created. 
内存页一旦被分配给slab,在memcache生命周期内不再更改,在内存总量确定的情形下,其它slab可能出现饿死现象;
为此1.4.11引入slab automove
The
algorithm is slow and conservative. If a slab class is seen as having
the highest eviction count 3 times 10 seconds apart, it will take a page
from a slab class which has had zero evictions in the last 30 seconds
and move the memory.
若某个slab在10秒内出现3次eviction,则从过去30秒内没有出现eviction的slab里挪取一个内存页使用;
分为手工分配和自动分配:
手工:  -o slab_reassign;在mc运行时输入echo "slabs reassign 1 4" | nc localhost 11211
自动: -o slab_reassign, slab_automove;mc每10秒进行一次重分配,手工暂停echo  "slabs automove 0" | nc localhost 11211
typedef struct {  
    unsigned int size;          /* 每个item大小, sizes of items */  
    unsigned int perslab;       /* 每个page中包含多少个item , how many items per slab */  
  
    void **slots;               /* 空闲的item指针, list of item ptrs */  
    unsigned int sl_total;      /* 以分配空闲的item 个数, size of previous array */  
    unsigned int sl_curr;       /* 当前空闲的item位置(也就是实际空闲item个数),从后往前的, first free slot */  
  
    void *end_page_ptr;         /* 指向最后一个页面中空闲的item开始位置, pointer to next free item at end of page, or 0 */  
    unsigned int end_page_free; /* 最后一个页面,item个数, number of items remaining at end of last alloced page */  
  
    unsigned int slabs;         /* 实际使用slab(page)个数 how many slabs were allocated for this class */  
  
    void **slab_list;           /* 所有page的指针, array of slab pointers */  
    unsigned int list_size;     /* 已经分配page指针个数,size of prev array */  
  
    unsigned int killing;       /* index+1 of dying slab, or zero if none */  
    size_t requested;           /* 所有被使用了的内存的大小, The number of requested bytes */  
} slabclass_t;

LRU和expired item
memcache并不会监视和清理过期数据,而是在客户端get时检查,称为lazy expiration。
item被检测到超时并不会被删除,而是放入slab->slots头部;
do_item_get --
   --判断该item是否过期
   do_item_unlink(it, hv);//将item从hashtable和LRU链中移除             
   do_item_remove(it);//删除item 
do_item_remove

  item_free(it);//释放item  
    slabs_free(it, ntotal, clsid);//slabclass结构执行释放 
           do_slabs_free(ptr, size, id);//执行释放 
以下是do_slabs_free的代码,将expired item放入slab->slots的头部       
    it = (item *)ptr;  
    it->it_flags |= ITEM_SLABBED;//修改item的状态标识,修改为空闲  
    it->prev = 0;//断开数据链表  
    it->next = p->slots;  
    if (it->next) it->next->prev = it;  
    p->slots = it; 
问:expired item何时被重用?
1 slab在新加item时会先查看LRU队尾;
2 如果队尾的item恰巧超时则重用,否则执行slabs_alloc;这一过程循环5次,若还没有找到可用item,则再次调用slabs_alloc;
3 slabs_alloc依次尝试  a slab->slot即expired item链表;  b slab->end_page_ptr 最后一个页面的空闲item; c 分配新的内存页
也就是说,只有LRU最后的5个元素状态为expired时,才有机会直接重用LRU,否则会依次尝试expired item list和slab的最后一个内存页的free item;

以下是代码实现
 
当客户端执行add操作,即往slab添加item时,调用do_item_alloc;
do_item_alloc

    mutex_lock(&cache_lock);//执行LRU锁 存储时,会尝试从LRU中选择合适的空间的空间  
    int tries = 5;//如果LRU中尝试5次还没合适的空间,则执行申请空间的操作 
    search = tails[id];//第id个LRU表的尾部

    
    /* We walk up *only* for locked items. Never searching for expired

    for (; tries > 0 && search != NULL; tries--, search=search->prev) {

        uint32_t hv = hash(ITEM_key(search), search->nkey, 0);//获取分段锁

        if ((search->exptime != 0 && search->exptime < current_time)  || (search->time <= oldest_live && oldest_live <= current_time)) { //过期时间的判断  
            it = search;

        } else if ((it = slabs_alloc(ntotal, id)) == NULL) {//申请合适的slabclass  
          ......
        } 
        break;  
    }

    if (!tried_alloc && (tries == 0 || search == NULL))//5次循环查找,未找到合适的空间  
        it = slabs_alloc(ntotal, id);//则从内存池申请新的空间

    return it;  
}

注:每次新分配item时,先进行5次循环:检查LRU尾部item是否过期,过期则重用,否则尝试slabs_alloc申请新内存;  若5次后仍未获取可用内存,则再次尝试slabs_alloc申请内存;
slabs_alloc
       pthread_mutex_lock(&slabs_lock);
    ret = do_slabs_alloc(size, id);
    pthread_mutex_unlock(&slabs_lock);

do_slabs_alloc(const size_t size, unsigned int id)
    p = &slabclass[id];  
    /* fail unless we have space at the end of a recently allocated page, we have something on our freelist, or we could allocate a new page */  
    // 1 最后面的页面有空间 2 空闲的地方有空间 3 分配一个新的页面  
    if (! (p->end_page_ptr != 0 || p->sl_curr != 0 ||  do_slabs_newslab(id) != 0)) {  
        /* We don't have more memory available */  
        ret = NULL;  
    } else if (p->sl_curr != 0) {  
        /* return off our freelist */  
        //从空闲(回收)地方分配  
        ret = p->slots[--p->sl_curr];  
    } else {  
        /* if we recently allocated a whole page, return from that */  
        assert(p->end_page_ptr != NULL);  
        ret = p->end_page_ptr;  
        if (--p->end_page_free != 0) {  
            p->end_page_ptr = ((caddr_t)p->end_page_ptr) + p->size;  
        } else {  
            p->end_page_ptr = 0;  
        }  
    }  

    if (ret) {  
        p->requested += size;  
        MEMCACHED_SLABS_ALLOCATE(size, id, p->size, ret);  
    } else {  
        MEMCACHED_SLABS_ALLOCATE_FAILED(size, id);  
    }  
  
    return ret;  
}

do_slabs_newslab--即为该slab新分配一个数据页;
    int len = p->size * p->perslab; 
    memory_allocate((size_t)len))

memcached-slab内存管理的更多相关文章

  1. memcached的内存管理与删除机制

    memcached的内存管理与删除机制 简介 注意:Memcache最大的value也只能是1M的空间,超过1M的数据无法保存(修改memcache源代码).   注意:内存碎片化永远都存在,只是哪一 ...

  2. nginx slab内存管理

    本来这一篇作为nginx系列的开头是不合适的,不过由于nginx进程框架自己的梳理还没完成,这部分又刚好整理完了,就从这开始吧.这儿谈的是nginx的slab的内存管理方式,这种方式的内存管理在ngi ...

  3. Linux中的Buffer Cache和Page Cache echo 3 > /proc/sys/vm/drop_caches Slab内存管理机制 SLUB内存管理机制

    Linux中的Buffer Cache和Page Cache echo 3 > /proc/sys/vm/drop_caches   Slab内存管理机制 SLUB内存管理机制 http://w ...

  4. memcached整理の内存管理及删除机制

    内存的碎片化 如果用C语言直接malloc,free来向操作系统申请和释放内存时,在不断申请和释放的过程中,形成了一些很小的内存片段,无法再利用.这种空闲但无法利用内存的现象称为内存的碎片化. sla ...

  5. memcached 的内存管理与删除机制

    1:内存的碎片化 如果用 c 语言直接 malloc,free 来向操作系统申请和释放内存时, 在不断的申请和释放过程中,形成了一些很小的内存片断,无法再利用. 这种空闲,但无法利用内存的现象,--- ...

  6. 关于linux kernel slab内存管理的一点思考

    linux kernel 内存管理是个很大的话题,这里记录一点个人关于slab模块的一点思考总结. 有些书把slab介绍成高速缓存,这会让人和cache,特别是cpu cache混淆,造成误解.sla ...

  7. Memcached 之内存管理与删除机制

    一.内存的碎片化 如果用c语言直接 malloc,free 来向操作系统申请和释放内存时,在不断的申请和释放过程中,形成了一些很小的内存片断,无法再利用,这种空闲,但无法利用内存的现象称为内存的碎片化 ...

  8. memcached 内存管理 分析(转)

    Memcached是一个高效的分布式内存cache,了解memcached的内存管理机制,便于我们理解memcached,让我们可以针对我们数据特点进行调优,让其更好的为我所用.这里简单谈一下我对me ...

  9. Memcached源码分析之内存管理

    先再说明一下,我本次分析的memcached版本是1.4.20,有些旧的版本关于内存管理的机制和数据结构与1.4.20有一定的差异(本文中会提到). 一)模型分析在开始解剖memcached关于内存管 ...

  10. Memcached 内存管理详解

    Memcached是一个高效的分布式内存cache,了解memcached的内存管理机制,便于我们理解memcached,让我们可以针对我们数据特点进行调优,让其更好的为我所用. 首先需要我们先了解两 ...

随机推荐

  1. Codeforces 1149 B - Three Religions

    B - Three Religions 思路:dp dp[i][j][k]:a的前i个和b的前j个和c的前k个能构成的最前面的位置 删字符时状态不用改变,加字符时只会改变1*250*250个状态 代码 ...

  2. c#系统泛型委托

    Action<T> 无返回值的系统泛型委托 namespace ConsoleApp1 { public class UserInfo { public int Id { get; set ...

  3. Docker清除容器镜像命令:

    # ~/.bash_aliases # Kill all running containers. alias dockerkillall='docker kill $(docker ps -q)' # ...

  4. crontab踩坑(二):Unit crond.service could not be found.

    这是因为Ubuntu上的服务名称是cron不是crond.所以你的命令应该是: sudo service cron start

  5. hive数据仓库表设计之(矮宽表+高窄表)

    昨天面对某客户域做表关联的时候发现了. 有两张相同内容的主表.但是表的设计结构并不相同: (每个领域都有主表,每次往这个领域(库)添加新表的时候一般都会join 主表,从而有唯一的主键id) 这两个表 ...

  6. pip command not found

    [root@ Python-2.7.9]# pip install jinja2 -bash: pip: command not found 解决 [root@ ~]#  yum -y install ...

  7. JS 中获取服务器时间的注意点

    在通过js获取服务器时间时,遇到了小小的问题,但造成的影响挺大的,所以写出来提醒大家,在获取服务器时间时一定要细心要多测试多验证. js 中使用以下方法获取服务器时间时要注意两点: 1.xhr.ope ...

  8. SQL Server孤立用戶

    如何解决孤立用户问题 http://blog.csdn.net/zzl1120/article/details/7394468 SQL SERVER孤立用户问题解决方法 http://www.2cto ...

  9. 防止sql注入的参数化查询

    参数化查询为什么能够防止SQL注入 http://netsecurity.51cto.com/art/201301/377209.htm OleDbDataAdapter Class http://m ...

  10. BZOJ 4070: [Apio2015]雅加达的摩天楼 根号分治+spfa

    此题卡Dijkstra... Code: #include <bits/stdc++.h> #define N 30005 #define M 4000000 #define ll lon ...