深入理解Linux内核内存管理：从伙伴系统到SLUB分配器生产级调优实战

导言：为什么你需要真正理解Linux内存管理

在日常运维和性能调优中，内存问题是最常见的瓶颈之一。从Java应用的OOM崩溃，到数据库缓存命中率骤降，再到容器环境中莫名奇妙地被Kill——这些问题的根因，几乎都指向同一个地方：Linux内核内存管理子系统。

本文不会停留在"free -m看看可用内存"的表面分析。我们将深入内核源码级别，系统地理解：物理页面如何被伙伴系统管理、SLUB分配器如何高效处理小对象分配、内核如何应对内存碎片、OOM Killer何时触发又如何选择牺牲品，以及生产环境中数百个vm.*参数究竟该如何调优。

一、物理内存模型：从节点到zone到页面

1.1 NUMA架构下的节点组织

现代多核服务器普遍采用NUMA（非统一内存访问）架构。Linux内核将物理内存组织为节点(pg_data_t)，每个NUMA节点包含若干个zone。

// 核心数据结构：内存节点
struct pglist_data {
    struct zone node_zones[MAX_NR_ZONES];    // 内存区域数组
    struct zonelist node_zonelists[MAX_ZONELISTS]; // 分配回退列表
    int nr_zones;                            // 节点中zone的数量
    struct page *node_mem_map;               // 页面描述符数组
    unsigned long node_start_pfn;            // 起始页面帧号
};

常见的zone类型：

64位系统（x86_64）已取消ZONE_HIGHMEM，内核可以直接映射全部物理内存。

1.2 页面描述符：struct page

系统中的每个物理页面都对应一个struct page描述符，它们被存放在节点的node_mem_map数组中。这个结构体极其紧凑（通过union压缩），包含：

struct page {
    unsigned long flags;      // 页面状态标志(PG_locked, PG_dirty等)
    atomic_t _refcount;       // 引用计数
    atomic_t _mapcount;       // 映射到页表的次数
    unsigned long private;    // 私有数据指针
    void *virtual;            // 内核虚拟地址(针对高端内存)
    // ... union中还有LRU链表节点、slab相关信息等
};

二、伙伴系统（Buddy System）：物理页面的分配引擎

2.1 核心算法思想

伙伴系统是Linux内核物理页面分配的核心算法，由Knowlton于1965年提出。其核心思想是将空闲页面组织为2^n大小的块链表，分配时向上分裂，释放时向下合并。

// 每个zone包含11个free_area，对应order 0~10
struct free_area {
    struct list_head free_list[MIGRATE_TYPES]; // 按迁移类型分链表
    unsigned long nr_free;                      // 空闲块数量
};

struct zone {
    struct free_area free_area[MAX_ORDER];      // MAX_ORDER=11
    ...
};

分配流程：从请求的order开始，在对应free_area的空闲链表中寻找。若找不到，则向更大的order层寻找，找到后不断对半分裂（直到得到所需order的块）。释放时若发现相同order的伙伴块也空闲，则合并为更大order的块。

2.2 伙伴块判定方法

两个块互为"伙伴"的条件：大小相同（2^n个页面）、物理地址连续、且合并后的块起始地址能被2^(n+1)整除。内核通过XOR运算快速计算伙伴地址：

// buddy_pfn = pfn ^ (1 << order)
// 即将第order位取反，得到伙伴块的pfn

2.3 迁移类型：碎片防御的第一道防线

Linux将空闲页面按迁移类型(Migration Type)分类，防止不可移动页面破坏可移动页面的连续性：

这种分类使得同类页面聚集在一起，为后续的页面碎片整理（compaction）奠定基础。

三、SLUB分配器：小对象分配的性能之王

3.1 SLAB家族演进史

Linux内核小对象分配器经历了三代演进：

3.2 SLUB核心数据结构

struct kmem_cache {
    struct kmem_cache_cpu __percpu *cpu_slab;  // 每CPU缓存
    struct kmem_cache_node *node[MAX_NUMNODES]; // 每节点半满链表
    unsigned int size;          // 对象实际大小
    unsigned int object_size;   // 包含元数据的对象大小
    unsigned long flags;        // 分配标志（如SLAB_ACCOUNT）
    unsigned int offset;        // 下一个空闲对象偏移量
    const char *name;           // 缓存名称（出现在slabinfo中）
    struct list_head list;      // 全局缓存链表（slab_caches）
};

3.3 三级分配路径

SLUB采用三级分配策略，逐级降级：

1. CPU slab（fast path）：per-cpu变量freelist指向下一个空闲对象，CPU partial链表。无锁、O(1)、NUMA本地。
2. Node partial slab：当CPU缓存耗尽时，从NUMA节点的partial slab列表中获取。需自旋锁但仍在本地节点。
3. 伙伴系统分配新slab：当所有partial都用完时，向伙伴系统申请新的页面作为slab。开销最大。

3.4 kmem_cache vs kmalloc

kmalloc系列函数本质上是对预创建的kmem_cache的封装：内核在启动时预先创建了kmalloc-8到kmalloc-8192共约9个大小级别的通用缓存（x86_64上为8, 16, 32, 64, 96, 128, 192, 256, 512, 1024, 2048, 4096, 8192）。申请100字节时实际分配128字节。

调试技巧：cat /proc/slabinfo可查看所有slab缓存的活动对象数、每slab对象数等详细信息。

四、页面回收与OOM Killer

4.1 LRU链表算法

内核通过LRU（Least Recently Used）页面链表实现页面回收。自2.6内核起采用双LRU链表：

enum lru_list {
    LRU_INACTIVE_ANIM = 0,  // 非活跃文件页
    LRU_ACTIVE_FILE = 1,    // 活跃文件页
    LRU_INACTIVE_ANON = 2,  // 非活跃匿名页
    LRU_ACTIVE_ANON = 3,    // 活跃匿名页
    LRU_ISOLATED_ANON = 4,  // 隔离匿名页(临时)
    LRU_ISOLATED_FILE = 5,  // 隔离文件页(临时)
};

页面在active和inactive链表间移动：新分配的页进入inactive，被第二次访问时提升到active；shrinker定期将active链表尾端的页降级到inactive，若被回收的inactive页从未被引用则直接释放。

4.2 交换分区与回收平衡

内核通过swappiness参数（默认60，范围0-200）控制匿名页与文件页回收的比例：

• swappiness=0：优先回收文件缓存，仅在内核检测到内存压力极大时才交换匿名页
• swappiness=100：匿名页和文件页按LRU热度等比例回收
• swappiness>100：允许超过等比例地优先交换匿名页

4.3 OOM Killer机制

当内存分配请求无法满足且所有回收手段都已失败时，内核触发OOM（Out-Of-Memory）Killer选择一个进程终止以释放内存。

// oom_badness() 评分方法（简化版）
points = total_vm_pages;  // 基础分 = 进程占用的总页面数
adj = (long)p->signal->oom_score_adj;
if (adj == OOM_SCORE_ADJ_MIN) return 0; // -1000表示永不杀
points += adj * (total_vm_pages / 1000); // 按比例调整OOM分数
return points > 0 ? points : 1; // 最低分1

评分策略：占用内存越多得分越高，越容易被kill。oom_score_adj范围-1000到1000，-1000表示永不选中。对关键进程（如数据库主进程、监控agent）应设为-1000或较低值。

五、透明大页（THP）与CMA

5.1 透明大页机制

透明大页（Transparent Huge Pages, THP）通过将2MB或1GB大页面替代传统4KB页面，减少TLB未命中和页表遍历开销，提升内存密集型应用性能。
THP模式由/sys/kernel/mm/transparent_hugepage/enabled控制：

• always：始终尝试分配大页（可能引发内存膨胀和延迟抖动）
• madvise：只有madvise(M_HUGEPAGE)标记的区域才使用大页
• never：禁用THP（数据库场景推荐）

5.2 连续内存分配器CMA

CMA（Contiguous Memory Allocator）在系统启动时预留一块物理内存，平时可被伙伴系统复用（作为可移动页面），应用程序需要连续大内存时，CMA会迁移/回收这块区域中的页面以满足分配需求。这对DMA设备（GPU、摄像头等）尤为重要，避免了预留内存被浪费。

六、生产级vm参数调优实战

6.1 数据库/缓存场景

# /etc/sysctl.d/99-memory.conf
# 尽可能减少swap使用，避免页面回收对数据库性能的影响
vm.swappiness = 1
# 降低脏页刷新阈值，减少突发IO
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
# 禁用透明大页（避免大页分配期间的延迟抖动）
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# 增大最小空闲KB，减少碎片化开销
vm.min_free_kbytes = 262144  # 256MB（大内存机器）

6.2 Web/应用服务器场景

# /etc/sysctl.d/99-web.conf
# 平衡文件系统缓存和应用内存回收
vm.swappiness = 10
# 适度增大脏页阈值，提升突发写入吞吐
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
# 启用透明大页（某些场景如Hadoop/Spark受益）
# echo always > /sys/kernel/mm/transparent_hugepage/enabled
# 提升脏页多次检查效率
vm.dirty_bytes = 0
vm.dirty_background_bytes = 0

6.3 容器/K8s场景

# 容器环境下关闭swap
vm.swappiness = 0
# 降低脏页刷新与回写的比率，避免容器存储带宽被占满
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10
# 适当增加脏页过期时间，提升突发写性能
vm.dirty_expire_centisecs = 2000

七、内存问题诊断工具箱

碎片排查口诀：buddyinfo看order-4以上区块是否丰富 → slabinfo看是否有缓存膨胀 → vmstat看pgscan_*是否持续扫描 → 必要时触发compaction（echo 1 > /proc/sys/vm/compact_memory）。

八、内存碎片整理（Memory Compaction）

Linux内核自2.6.38起引入内存碎片整理机制，通过migrate扫描散落在可移动页面中的不可移动页面，将它们迁移到别处，从而腾出连续的较大块内存。参数控制：

# 触发手动整理(一次性异步操作)
echo 1 > /proc/sys/vm/compact_memory
# 控制内核自动整理的积极程度(0-100，默认10)
vm.compaction_proactiveness = 10
# 控制kcompactd是否在检测到碎片时自动唤醒
vm.watermark_scale_factor = 1000  # 控制watermark对compact的触发灵敏度

碎片整理会产生延迟抖动（需等待大量页面迁移），在延迟敏感的实时系统中应降低proactiveness或直接禁用。

结语

Linux内存管理是一个精密而复杂的系统工程。理解伙伴系统的分配原理和碎片防御、SLUB的分配路径与性能优化、页面回收的LRU双链表算法、OOM Killer的选择逻辑，不仅能够帮助我们快速定位生产环境的性能瓶颈，更能指导我们从系统层面做出正确的参数配置决策。

记住：free不是真的free，vm.swappiness=0不等于oom_score_adj=-1000。当你对底层机制有了深刻理解，每一个参数调整都将有的放矢。