理解memcached的内存存储机制

Slab Allocator内存分配机制

Memcached默认情况下采用了名为Slab Allocator的机制分配、管理内存。

0. 之前内存分配的弊端

在该机制出现以前，内存的分配是通过对所有记录简单地进行malloc和free来进行的。但是，这种方式会导致内存碎片，加重操作系统内存管理器的负担，最坏的情况下，会导致操作系统比memcached进程本身还慢。Slab Allocator就是为解决该问题而诞生的。

---

1. 解决方案

Slab Allocator的基本原理是按照预先规定的大小，将分配的内存以page为单位，默认情况下一个page是1M，可以通过-I参数在启动时指定，分割成各种尺寸的块（chunk）， 并把尺寸相同的块分成组（chunk的集合），如果需要申请内存时，memcached会划分出一个新的page并分配给需要的slab区域。page一旦被分配在重启前不会被回收或者重新分配，以解决内存碎片问题。

Page

分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。

Chunk

用于缓存记录的内存空间。

Slab Class

相同大小的chunk组成的组。

Memcached并不是将所有大小的数据都放在一起的，而是预先将数据空间划分为一系列slabs，每个slab只负责一定范围内的数据存储。memcached根据收到的数据的大小，选择最适合数据大小的slab。memcached中保存着slab内空闲chunk的列表，根据该列表选择chunk，然后将数据缓存于其中。

如图所示，每个slab只存储大于其上一个slab的size并小于或者等于自己最大size的数据。例如：100字节大小的字符串会被存到slab2（88-112）中，每个slab负责的空间是不等的，memcached默认情况下下一个slab的最大值为前一个的1.25倍，这个可以通过修改-f参数来修改增长比例。

---

2. 带来的新的问题

Slab Allocator解决了当初的内存碎片问题，但新的机制也给memcached带来了新的问题。chunk是memcached实际存放缓存数据的地方，这个大小就是管理它的slab的最大存放大小。每个slab中的chunk大小是一样的，如上图所示slab1的chunk大小是88字节，slab2是112字节。由于分配的是特定长度的内存，因此无法有效利用分配的内存。例如，将100字节的数据缓存到128字节的chunk中，剩余的28字节就浪费了。这里需要注意的是chunk中不仅仅存放缓存对象的value，而且保存了缓存对象的key，expire time， flag等详细信息。所以当set 1字节的item，需要远远大于1字节的空间存放。

memcached在启动时指定 Growth Factor因子（通过-f选项）， 就可以在某种程度上控制slab之间的差异。默认值为1.25。

---

3. slab的内存分配具体过程如下：

Memcached在启动时通过-m参数指定最大使用内存，但是这个不会一启动就占用完，而是逐步分配给各slab的。
如果一个新的数据要被存放：

1. 首先选择一个合适的slab，然后查看该slab是否还有空闲的chunk，如果有则直接存放进去；如果没有则要进行申请，slab申请内存时以page为单位，无论大小为多少，都会有1M大小的page被分配给该slab（该page不会被回收或者重新分配，永远都属于该slab）。

2. 申请到page后，slab会将这个page的内存按chunk的大小进行切分，这样就变成了一个chunk的数组，再从这个chunk数组中选择一个用于存储数据。

3. 若没有空闲的page的时候，则会对该slab进行LRU，而不是对整个memcache进行LRU。

以上大致讲解了memcache的内存分配策略。