memcached内存管理

Memcached 内存管理：Slab Allocator 机制详解

Memcached 作为高性能内存缓存系统，其内存管理机制直接影响性能和资源利用率。为解决传统内存分配（malloc/free）导致的内存碎片化问题，Memcached 采用了 Slab Allocator 机制，通过预分配固定大小的内存块，实现高效的内存复用。本文深入解析这一机制的原理、优缺点及优化策略。

内存碎片化问题与 Slab 机制的诞生

传统内存分配方式（如 C 语言的 malloc 和 free）在频繁分配和释放不同大小的内存块时，会产生大量内存碎片：

碎片是指无法被利用的空闲内存（如多次分配 / 释放后，内存中存在大量小于申请大小的零散空间）。
碎片积累会导致内存利用率下降，甚至出现 “内存充足但无法分配连续空间” 的矛盾。

为解决这一问题，Memcached 引入 Slab Allocator 机制，核心思想是：按固定大小预分配内存块，根据数据大小匹配最合适的块，避免碎片化。

Slab Allocator 核心组件与工作流程

核心组件

Slab（内存 slab 区）：Memcached 将内存划分为多个 Slab，每个 Slab 对应一种固定大小的内存块（chunk）。
Page（页）：每个 Slab 由多个 Page 组成，Page 是内存分配的基本单位（默认大小为 1MB）。
Chunk（块）：每个 Page 被分割为多个大小相同的 Chunk，Chunk 是存储数据的最小单元（如 48B、60B、75B 等）。
Slab Class（Slab 类别）：具有相同 Chunk 大小的 Slab 集合，每个类别用 class ID 标识（如 class 1 对应 48B Chunk，class 2 对应 60B Chunk 等）。

工作流程

初始化 Slab：Memcached 启动时，根据增长因子（Growth Factor） 预分配多种 Slab Class，每个类别包含若干 Page，Page 被分割为固定大小的 Chunk。
- 例如，增长因子为 1.25 时，Chunk 大小按 48B → 60B（48×1.25）→ 75B（60×1.25）→ … 递增，直至 1MB（最大 Chunk size）。
数据存储：当写入键值对时：
- 计算数据（键 + 值 + 元数据）的总大小。
- 匹配最小且能容纳该数据的 Chunk 对应的 Slab Class。
- 从该 Slab Class 的空闲 Chunk 列表中分配一个 Chunk 存储数据。
内存复用：当数据被删除时，Chunk 不会归还给操作系统，而是被标记为 “空闲”，加入该 Slab Class 的空闲列表，供后续相同大小的数据复用。

示例：Slab 分配过程

假设增长因子为 1.25，某数据大小为 80B：

系统中存在 Chunk 大小为 75B（class 3）和 94B（class 4，75×1.25≈94）的 Slab Class。
80B 数据无法放入 75B Chunk，因此选择 class 4 的 94B Chunk 存储。

Slab 机制的优缺点

优点

消除内存碎片：Chunk 大小固定，分配和释放不会产生零散碎片，内存利用率稳定。
高效复用：空闲 Chunk 直接复用，避免频繁向操作系统申请 / 释放内存（减少系统调用开销）。
可预测性：内存分配行为可预测，便于性能调优。

缺点：内存浪费（内部碎片）

由于 Chunk 大小固定，当数据大小小于 Chunk 大小时，会产生内部碎片（Chunk 中未使用的空间）。

例如：80B 数据放入 94B Chunk，浪费 14B。
数据大小越接近 Chunk 大小，浪费越少；反之则浪费越严重（如 10B 数据放入 48B Chunk，浪费 38B）。

增长因子（Growth Factor）：平衡碎片与浪费

增长因子（-f 参数）决定了不同 Slab Class 的 Chunk 大小递增比例，默认值为 1.25。通过调整该参数，可平衡内存浪费和 Slab 类别数量：

增长因子越小（如 1.1）：
- Chunk 大小递增缓慢，Slab Class 数量多（如 48B → 53B → 58B…）。
- 优点：数据与 Chunk 大小更匹配，内存浪费少。
- 缺点：Slab Class 过多，管理开销增大，且可能消耗更多内存存储空闲列表。
增长因子越大（如 2.0）：
- Chunk 大小递增快，Slab Class 数量少（如 48B → 96B → 192B…）。
- 优点：Slab Class 少，管理简单。
- 缺点：内存浪费严重（如 97B 数据需放入 192B Chunk，浪费近 50%）。

实践建议

默认值（1.25）：适用于大多数场景，平衡浪费与管理开销。
定制化场景：
- 若存储数据大小差异小（如固定 100-200B），可减小增长因子（如 1.1）。
- 若数据大小差异大且对内存浪费不敏感，可增大增长因子（如 1.5）。

Slab 机制的其他特性

最大 Chunk 大小

单个 Chunk 的最大大小为 1MB（默认），超过此限制的数据无法存储（Memcached 会返回错误）。这也是 Memcached 不适合存储大对象（如大文件、二进制数据）的原因。

LRU 淘汰策略

当某个 Slab Class 的 Chunk 用尽时，Memcached 会采用 LRU（最近最少使用） 策略淘汰该类别中最久未访问的数据，腾出 Chunk 供新数据使用。

注意：淘汰仅发生在同一 Slab Class 内部，不会跨类别借用 Chunk（如 75B Chunk 用尽时，不会使用 94B Chunk 的空闲空间）。

内存预分配与动态扩展

启动时，Memcached 仅为每个 Slab Class 分配少量 Page（默认 1 个 Page = 1MB）。
当某个 Slab Class 的 Chunk 不足时，会动态向操作系统申请新的 Page（拆分后加入该类别），直至达到 -m 参数指定的总内存上限。

优化 Slab 内存管理的实践技巧

监控内存利用率：
使用 stats 命令查看 bytes（已用内存）和 limit_maxbytes（总内存），计算利用率。若利用率过低，可能存在严重的内部碎片。
调整增长因子：
根据数据大小分布调整 -f 参数。例如，通过 stats items 查看各 Slab Class 的使用情况，若某类别频繁淘汰数据且内部碎片大，可减小增长因子。
控制数据大小：
避免存储过大数据（>1MB 不支持），对中小数据进行分片（如将大 JSON 拆分为多个小键值对），减少内部碎片。
合理设置总内存：
通过 -m 参数分配足够内存，避免频繁触发 LRU 淘汰（淘汰操作会消耗 CPU 资源）