memcache的内存分配默认是采用了Slab Allocator的机制分配、管理内存。在该机制出现以前，内存的分配是通过对所有记录简单地进行malloc和free来进行的。 但是，这种方式会导致内存碎片，加重操作系统内存管理器的负担，最坏的情况下， 会导致操作系统比memcached进程本身还慢。Slab Allocator就是为解决该问题而诞生的。
The fundamental idea behind slab allocation technique is based on the observation that some kernel data objects are frequently created and destroyed after they are not needed anymore. This implies that for each allocation of memory for these data objects, some time is spent to find the best fit for that data object. Moreover, deallocation of the memory after destruction of the object contributes to fragmentation of the memory, which burdens the kernel some more to rearrange the memory.Slab 算法的发现是基于内核中内存使用的一些特点：一些需要频繁使用的同样大小数据经常在使用后不久又再次被用到；找到合适大小的内存所消耗的时间远远大于释放内存所需要的时间。所以Slab算法的发明人认为内存对象在使用之后不是立即释放给系统而是将它们用链表之类的数据结构管理起来以备将来使用，频繁分配和释放的内存对象应该用缓存管理起来。Linux的slab分配器就是基于这样的想法实现的，这个算法在空间和时间上都有很高的效率。
Slab Allocation的原理相当简单。它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定Figure 1中Growth Factor的取值为1.25，所以如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。每个slab的大小用page表示，默认是1MB，大于1MB数据默认忽略；每个chunk中存储一个item，默认是48byte；facter默认值是1.25；默认过期时间30天；
当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个 Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。
下面是参考其他人关于Slab Allocation的分析，http://blog.csdn.net/zhxp_870516/article/details/8468604
1.slab内存结构图：二维数组链表
2.slab内存分配实例
3.实例数据
4.计算slab占用内存
5.slab参数
进程内存区
slabclass元信息：1.1中是21byte，1.2中是200byte
Hashtable：1.1中位41MB，1.2中位65MB
数据内存区
slab默认大小为1048576byte（1MB），大于1MB数据忽略
chunk初始大小，1.1中是1byte，1.2中是48byte
增长因子factor
1.1中，chunk大小为初始大小*2^n，n为classid，即：
id为0的slab大小1byte，id为1的slab大小2byte，id为2的slab大小4byte...
id为20的slab，每chunk大小为1MB，只有一个chunk
1.2中有一个factor值，默认为1.25
96,120,152...