Linux 内存管理深入：从伙伴系统到 SLAB 分配器的底层机制与工程权衡
一、内存分配的工程困境：为什么内核需要三层分配器
在服务器高负载场景下，内存分配的效率直接决定系统的延迟上限。一个高频交易系统每秒执行数十万次内存分配，如果每次分配都从伙伴系统（Buddy System）申请，内部碎片率可达 50%。更严重的是，伙伴系统的分配操作需要获取全局锁，在多核环境下成为严重的性能瓶颈。
生产环境中的典型故障：一个 Redis 实例在大量小对象分配时，slab 通道配置不当导致频繁的 slab 创建和销毁，内存碎片率飙升，最终触发 OOM。这不是 Redis 自身的问题，而是对内核 SLAB 分配器机制理解不足导致的配置错误。
内核内存管理的核心矛盾是：外部碎片与内部碎片的权衡。伙伴系统通过 2^n 幂次对齐消除了外部碎片，但引入了严重的内部碎片；SLAB 分配器通过对象复用解决了内部碎片，但增加了管理开销。理解这三层分配器的协作机制，是做对性能优化决策的前提。
二、伙伴系统到 SLAB 的三层分配架构
Linux 内存管理采用三级分配架构：伙伴系统管理物理页帧、SLAB/SLUB 管理对象级分配、kmalloc 提供通用内核内存分配接口。
flowchart TB
subgraph 用户空间分配
A[malloc / free] –> B[glibc ptmalloc]
B –> C[brk / mmap 系统调用]
end
subgraph 内核空间分配
D[kmalloc / kfree] –> E{对象大小判断}
E –>|≤ kmalloc 最大尺寸| F[SLAB/SLUB 分配器]
E –>|> kmalloc 最大尺寸| G[直接从伙伴系统分配]
F –> H[slab 空闲对象链表]
H –>|slab 耗尽| I[从伙伴系统申请新 slab]
I –> J[伙伴系统<br/>2^n 页帧管理]
G –> J
end
C –> J
subgraph 伙伴系统核心
J –> K[MAX_ORDER=11<br/>阶数 0~10]
K –> L[阶0: 单页 4KB<br/>阶10: 1024页 4MB]
end
style F fill:#bbf,stroke:#333
style J fill:#fbb,stroke:#333
伙伴系统的核心机制：将空闲内存按 2^n 页帧组织成 11 个阶（order 0-10），分配时从目标阶取出一块，释放时检查"伙伴"是否空闲——如果空闲则合并为更高阶的块。伙伴的定义是：地址只有第 n 位不同的两个块互为伙伴。这个设计保证了外部碎片在释放时能被自动合并。
SLAB 分配器的对象复用：SLAB 的核心思想是为每种内核对象类型维护独立的缓存。每个缓存由多个 slab 组成，每个 slab 包含若干同类型对象。对象释放后不归还给伙伴系统，而是标记为空闲等待复用。这解决了两个问题：内部碎片（按对象实际大小分配）和初始化开销（复用已初始化的对象）。
SLUB 对 SLAB 的改进：SLAB 分配器在 NUMA 系统上存在严重的锁竞争问题。SLUB 的核心改进是将 per-CPU 缓存从复杂的队列简化为单链表，分配和释放都是无锁操作。当前主流内核默认使用 SLUB，但 SLAB 在某些特定场景（如需要对象构造/析构回调）仍有优势。
三、生产级内存分配监控与调优实现
以下代码展示了内核内存分配的监控工具和 SLAB 调优的工程实践：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
/* SLAB 缓存统计信息结构 */
typedef struct {
char name[64]; /* slab 名称 */
long obj_size; /* 单个对象大小 */
long obj_per_slab; /* 每 slab 对象数 */
long obj_active; /* 活跃对象数 */
long obj_total; /* 总对象数 */
long slab_active; /* 活跃 slab 数 */
long slab_total; /* 总 slab 数 */
long pages_per_slab; /* 每 slab 占用页数 */
long obj_per_alloc; /* 每次分配对象数 */
} slab_stat_t;
/**
* 从 /proc/slabinfo 读取 SLAB 统计信息
* 返回读取到的 slab 数量，-1 表示错误
*/
int read_slab_stats(slab_stat_t *stats, int max_entries)
{
FILE *fp = fopen("/proc/slabinfo", "r");
if (!fp) {
fprintf(stderr, "无法打开 /proc/slabinfo: %s\\n", strerror(errno));
return -1;
}
/* 跳过前两行头部信息 */
char line[512];
if (!fgets(line, sizeof(line), fp)) goto cleanup;
if (!fgets(line, sizeof(line), fp)) goto cleanup;
int count = 0;
while (count < max_entries && fgets(line, sizeof(line), fp)) {
slab_stat_t *s = &stats[count];
/* 解析 slabinfo 行格式：
* name <obj_size> <obj_per_slab> <pages_per_slab> <tunable…>
* <obj_active> <obj_total> <slab_active> <slab_total> … */
int parsed = sscanf(line, "%63s %ld %ld %ld : tunables %*d %*d %*d : "
"slabdata %ld %ld %ld",
s->name, &s->obj_size, &s->obj_per_slab,
&s->pages_per_slab,
&s->slab_active, &s->slab_total,
&s->obj_per_alloc);
if (parsed >= 4) {
/* 计算活跃对象数和总对象数 */
s->obj_active = s->slab_active * s->obj_per_slab;
s->obj_total = s->slab_total * s->obj_per_slab;
count++;
}
}
cleanup:
fclose(fp);
return count;
}
/**
* 计算 SLAB 内存碎片率
* 碎片率 = (总对象数 – 活跃对象数) / 总对象数
* 高碎片率意味着大量空闲对象占用内存未释放
*/
double calc_slab_fragmentation(const slab_stat_t *s)
{
if (!s || s->obj_total == 0) return 0.0;
return (double)(s->obj_total – s->obj_active) / s->obj_total;
}
/**
* 分析 SLAB 内存使用情况，输出异常告警
* 阈值基于生产环境经验值，可按需调整
*/
void analyze_slab_usage(const slab_stat_t *stats, int count)
{
long total_slab_pages = 0;
long total_wasted_pages = 0;
printf("%-24s %8s %8s %8s %8s %8s\\n",
"SLAB名称", "对象大小", "活跃", "总计", "碎片率", "浪费页");
printf("%-24s %8s %8s %8s %8s %8s\\n",
"——–", "——", "—-", "—-", "——", "——");
for (int i = 0; i < count; i++) {
const slab_stat_t *s = &stats[i];
double frag = calc_slab_fragmentation(s);
long wasted_pages = (s->obj_total – s->obj_active) *
s->obj_size / 4096;
total_slab_pages += s->slab_total * s->pages_per_slab;
total_wasted_pages += wasted_pages;
/* 碎片率超过 60% 或浪费页数超过 1000 页的 slab 需要关注 */
if (frag > 0.6 || wasted_pages > 1000) {
printf("%-24s %8ld %8ld %8ld %7.1f%% %8ld\\n",
s->name, s->obj_size, s->obj_active,
s->obj_total, frag * 100, wasted_pages);
}
}
printf("\\n总 SLAB 内存: %ld 页 (%.1f MB)\\n",
total_slab_pages, total_slab_pages * 4.0 / 1024);
printf("浪费内存: %ld 页 (%.1f MB)\\n",
total_wasted_pages, total_wasted_pages * 4.0 / 1024);
if (total_slab_pages > 0) {
double overall_frag = (double)total_wasted_pages / total_slab_pages;
printf("整体碎片率: %.1f%%\\n", overall_frag * 100);
}
}
/**
* 调整 SLAB 缓存的 tunable 参数
* 通过 /sys/kernel/slab/<name> 接口修改
* 注意：需要 root 权限
*/
int tune_slab_cache(const char *slab_name, int batch_size, int min_partial)
{
char path[256];
int fd;
/* 设置 batchsize：每次从伙伴系统获取/释放的对象数
* 增大 batchsize 可减少锁竞争，但增加内存占用 */
snprintf(path, sizeof(path),
"/sys/kernel/slab/%s/batchsize", slab_name);
fd = open(path, O_WRONLY);
if (fd < 0) {
fprintf(stderr, "无法打开 %s: %s\\n", path, strerror(errno));
return -1;
}
char val[32];
snprintf(val, sizeof(val), "%d", batch_size);
if (write(fd, val, strlen(val)) < 0) {
fprintf(stderr, "写入 batchsize 失败: %s\\n", strerror(errno));
close(fd);
return -1;
}
close(fd);
/* 设置 min_partial：保留的最小部分空闲 slab 数
* 增大可减少 slab 创建/销毁的开销，但增加内存占用 */
snprintf(path, sizeof(path),
"/sys/kernel/slab/%s/min_partial", slab_name);
fd = open(path, O_WRONLY);
if (fd < 0) {
fprintf(stderr, "无法打开 %s: %s\\n", path, strerror(errno));
return -1;
}
snprintf(val, sizeof(val), "%d", min_partial);
if (write(fd, val, strlen(val)) < 0) {
fprintf(stderr, "写入 min_partial 失败: %s\\n", strerror(errno));
close(fd);
return -1;
}
close(fd);
return 0;
}
int main(void)
{
slab_stat_t stats[512];
int count = read_slab_stats(stats, 512);
if (count <= 0) {
fprintf(stderr, "读取 slab 统计信息失败\\n");
return 1;
}
analyze_slab_usage(stats, count);
return 0;
}
四、内存分配器的架构权衡与适用边界
伙伴系统的内部碎片问题：伙伴系统只能分配 2^n 个页帧，这意味着如果需要 3 页内存，实际分配 4 页，内部碎片率 25%。对于小对象密集的场景（如 dentry 缓存、inode 缓存），这个碎片率不可接受。这就是 SLAB 分配器存在的根本原因——它在伙伴系统之上做对象级分配，将内部碎片控制在对象大小的对齐开销内。
SLAB vs SLUB vs SLOB 的选择：
| SLAB | 需要构造/析构回调 | 对象复用率高 | NUMA 锁竞争严重 |
| SLUB | 通用服务器场景 | 无锁 per-CPU 缓存 | 调试信息较少 |
| SLOB | 嵌入式/内存受限 | 内存开销最小 | 分配性能最低 |
SLUB 的 per-CPU 缓存权衡：SLUB 为每个 CPU 维护一个空闲对象链表，分配和释放都是无锁操作。但 per-CPU 缓存中的对象无法被其他 CPU 使用，这意味着在 CPU 负载不均衡的场景下，可能出现一个 CPU 的缓存空闲而另一个 CPU 频繁从伙伴系统分配的情况。内核通过 cache_reap 机制定期回收 per-CPU 缓存，但回收间隔的设置是一个权衡——太频繁增加锁竞争，太稀疏浪费内存。
大页（Huge Pages）与 SLAB 的冲突：在启用透明大页（THP）的系统上，SLAB 分配器的行为可能受到影响。THP 倾向于合并小页为大页，但 SLAB 的 slab 是按小页对齐的。如果 THP 在 slab 活跃期间合并了相邻页，可能导致 slab 的伙伴合并逻辑出错。生产环境中，建议对 SLAB 密集型工作负载禁用 THP。
禁用场景：在内存小于 256MB 的嵌入式系统中，SLAB 的管理开销可能超过其节省的碎片开销，此时应使用 SLOB。在需要严格内存确定性保证的实时系统中，SLAB 的对象复用机制可能导致不可预测的缓存行为，应使用专用的内存池方案。
五、总结
Linux 内存管理的三级分配架构——伙伴系统、SLAB/SLUB、kmalloc——各自解决不同层次的碎片问题。伙伴系统通过 2^n 对齐消除外部碎片但引入内部碎片，SLAB 通过对象复用消除内部碎片但增加管理开销，SLUB 通过 per-CPU 无锁缓存解决 NUMA 锁竞争但牺牲了缓存均衡性。生产环境中的调优需要基于 /proc/slabinfo 的实际数据，关注碎片率和浪费页数，通过 batchsize 和 min_partial 参数在内存占用与分配性能之间找到平衡点。技术选型应基于工作负载特征而非通用推荐，内存受限场景用 SLOB，通用服务器用 SLUB，需要对象回调的用 SLAB。
