Linux内存管理深度实战：从页表映射到SLAB分配器与OOM Killer调优

一、虚拟内存与物理内存架构

Linux内核的内存管理子系统是整个操作系统中最复杂、最核心的模块之一。它通过虚拟内存机制为每个进程提供独立的地址空间，使得进程以为自己独占整个内存资源。本文将深入剖析 Linux 内存管理的核心机制，并结合生产环境实战调优经验，帮助读者掌握内存子系统的运行原理。

在 x86_64 架构下，Linux 使用四级页表（PGD→PUD→PMD→PTE）完成虚拟地址到物理地址的转换。每次地址转换理论上需要 5 次内存访问（4 次页表遍历 + 1 次实际数据访问），这显然太慢。因此 CPU 芯片内置了 TLB（Translation Lookaside Buffer）缓存最近使用的页表项，将平均访问次数降至接近 1 次。

// 查看当前系统 TLB 信息
$ cat /proc/cpuinfo | grep -i tlb
$ getconf PAGESIZE  // 通常 4096 bytes

当进程访问一个不在 TLB 中的虚拟地址时，CPU 会触发 Page Walk 硬件单元自动遍历页表。如果页表项不存在（页面未被分配），则触发 #PF 缺页异常，内核的缺页处理程序介入分配物理页面。

二、Buddy System 伙伴系统

物理内存管理采用伙伴系统（Buddy System）算法，将内存按 2^n 页框大小组织为 11 个链页（order 0~10，对应 1~1024 页，即 4KB~4MB）。分配时找到最小能满足需求的 order，若该 order 无空闲块，则从更大的 order 切割为两半（伙伴），一半分配，一半加入低阶链表。释放时检查伙伴是否空闲，若空闲则合并回高阶链表。

核心优势：有效减少外部碎片。低阶分配不会在高阶链表中留下空隙，最终可合并为大块连续内存。

// 查看当前 Buddy System 状态
$ cat /proc/buddyinfo
Node 0, zone   DMA      1    0    1    0    2    1    1    0    1    1    3
Node 0, zone  DMA32  6597  4095  2048  1024  512  256  128   64   32   16    8
Node 0, zone Normal  8192  4096  2048  1024  512  256  128   64   32   16    8

问题：当系统运行较长时间后，大块连续物理内存变得稀缺——因为伙伴系统无法将分散页面重排。这正是外部碎片问题的体现。Linux 通过内存规整（Memory Compaction）和 CMA（Contiguous Memory Allocator）来缓解。

三、Slab / SLUB 分配器

伙伴系统以页（4KB）为粒度分配，但内核对象通常只有几百字节（如 task_struct 约 7KB、inode 约 600B）。频繁向伙伴系统申请整页会导致严重的内部碎片。Slab 分配器（现代内核默认为 SLUB）作为伙伴系统与内核对象之间的缓存层：

1. 向伙伴系统申请一页或多页作为 Slab
2. 将 Slab 切分为多个等长 slot，每个 slot 存放一个对象
3. 分配对象时从空闲 slot 中取；释放时标记为空闲供重用

SLUB 优化：相比传统 Slab，SLUB 简化了管理结构（去掉复杂的 kmem_bufctrl），将空闲指针直接嵌入 object 的闲置内存区域，减少元数据开销，提升缓存局部性。

// 查看 Slab 分配器状态，定位内存泄漏或异常增长
$ cat /proc/slabinfo | head -20
$ slabtop -o  // 实时查看活跃 Slab 缓存

// 常见内核 Slab 缓存：
// dentry       - 目录项缓存（文件路径查找加速）
// inode_cache  - inode 缓存
// vm_area_struct - 虚拟内存区域描述符
// task_struct  - 进程描述符

生产案例：某高并发 Web 服务器出现可用内存持续下降但 free 显示充足（Cached 很高），经查是 dentry + inode 缓存过度增长导致。通过调整 vfs_cache_pressure 参数加速回收：

// 增大回收压力（默认100，越大回收越激进）
$ sysctl -w vm.vfs_cache_pressure=200

四、mmap 内存映射机制

mmap 是 Linux 中最强大的 I/O 机制之一，将文件或设备映射到进程虚拟地址空间，实现"文件即内存"的编程模型。内核通过 VMA（Virtual Memory Area）红黑树管理进程的内存映射区域。

mmap 的两种类型：

• 文件映射（File-backed）：映射磁盘文件，访问时触发缺页加载到 Page Cache，写回时由 pdflush 线程异步刷盘
• 匿名映射（Anonymous）：不关联文件（MAP_ANONYMOUS），用于 malloc 大内存分配、共享内存等场景

// Linux 常用 mmap 场景示例
void* addr = mmap(NULL, length, PROT_READ|PROT_WRITE,
                  MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);

// 映射文件到内存
int fd = open("data.bin", O_RDONLY);
void* file_mem = mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, fd, 0);
// 直接通过指针访问文件内容，避免 read() 系统调用的用户态-内核态拷贝

Page Cache 与映射：文件映射共享 Page Cache，多进程 mmap 同一文件时指向相同的物理页面——这比传统 read/write 减少一次用户态拷贝（零拷贝技术的基础）。

五、OOM Killer 与内存超分配

Linux 默认允许内存超分配（Overcommit），即承诺的虚拟内存可超过物理内存+交换空间总和。这是因为大多数进程不会真正使用申请的全部内存（如 malloc 1GB 但只写 10MB）。

// overcommit 模式
// 0 = 启发式检查（默认）：大块申请拒绝
// 1 = 总是允许：极端超分配
// 2 = 严格模式：申请不超过 Swap + 物理内存 × overcommit_ratio%
$ cat /proc/sys/vm/overcommit_memory
$ cat /proc/sys/vm/overcommit_ratio  // 默认 50

当物理内存真正耗尽且无法回收时，内核触发 OOM Killer。OOM Killer 通过 oom_score 选择"最该死"的进程终止：

// 查看进程 OOM 评分
$ cat /proc/[pid]/oom_score        // 0~1000，越大越可能被杀
$ cat /proc/[pid]/oom_score_adj    // 管理员可调整（-1000 保护，+1000 优先杀）

// 关键服务保护示例
$ echo -1000 > /proc/[mysql_pid]/oom_score_adj  // 保护 MySQL
$ echo 1000 > /proc/[batch_job_pid]/oom_score_adj // 优先杀批处理任务

OOM 评分因素：内存占用比例（主导）、运行时间（越新越容易被杀）、特权级（root 进程降分）、oom_score_adj 调整值。

六、NUMA 内存本地化

多核服务器普遍采用 NUMA（Non-Uniform Memory Access）架构，CPU 访问本地节点的内存延迟约 100ns，访问远端节点内存延迟可达 200ns+。Linux 通过 NUMA 感知的内存分配策略优化本地访问。

// 查看 NUMA 拓扑
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14
node 0 size: 32768 MB
node 1 cpus: 1 3 5 7 9 11 13 15
node 1 size: 32768 MB

// NUMA locality 监控
$ numastat -p [pid]
                       Node 0    Node 1
numa_hit              2845921     12043
numa_miss               8934    384721  // 高miss说明绑定不合理
numa_foreign           12043      8934

NUMA 策略调优：

• numactl --cpunodebind=0 --membind=0：绑定进程到 NUMA 节点 0
• AutoNUMA Balancing：内核 3.8+ 自动将页面迁移到访问它的 CPU 所在节点
• Zone Reclaim Mode：节点内存不足时选择本地回收还是分配远端内存

// 大数据/数据库服务的最佳实践
$ numactl --cpunodebind=0,1 --interleave=all ./redis-server
// interleave 策略在多个节点交替分配，适合内存密集型服务

七、HugePage 大页内存

标准页 4KB 在内存密集型场景下导致 TLB 压力巨大。例如 128GB 内存对应 33554432 个 4KB 页，CPU TLB 通常只缓存 64~1024 个页表项。HugePage 使用 2MB（或 1GB）大页，将 TLB 覆盖率提升 512 倍。

// 标准 HugePage 配置
// 1. 分配 1024 个 2MB 大页 = 2GB
$ echo 1024 > /proc/sys/vm/nr_hugepages
$ mount -t hugetlbfs hugetlbfs /dev/hugepages

// 2. 应用程序使用
void* ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
                 MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0);

// Transparent HugePage（THP）——透明大页
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[madvise] always madvise
// 建议：数据库场景设为 madvise，避免 khugepaged CPU 开销

THP 风险：khugepaged 内核线程持续扫描进程内存尝试合并为大页，在某些高并发数据库（如 MongoDB、Redis 建议禁用 THP）场景下反而造成延迟抖动。

八、生产环境内存调优实战总结

// 综合调优示例（内存 64GB 的数据库服务器）
vm.swappiness = 1              // 几乎不使用 Swap
vm.dirty_ratio = 40            // 允许更多脏页在内存中
vm.dirty_background_ratio = 5  // 提前异步刷盘
vm.min_free_kbytes = 2097152   // 保留 2GB 应急内存
vm.overcommit_memory = 0       // 启发式超分配
vm.vfs_cache_pressure = 50     // 优先保留文件缓存

Linux 内存管理是一个精密的系统工程，从底层的 Buddy System 到上层的 SLUB 分配器，再到 OOM Killer 的最后防线，每一个环节都对系统稳定性至关重要。深入理解这些机制，才能在生产环境中做出正确的调优决策。