1. 项目概述从开机到应用Linux内存管理的全景图刚接触Linux内核开发或者系统调优的朋友经常会听到“伙伴系统”、“Slab分配器”、“vmalloc”这些名词感觉它们既神秘又分散。实际上这些概念串联起来就是Linux操作系统从按下电源键那一刻起到你的应用程序成功申请到一块内存的完整故事。今天我们不谈枯燥的理论堆砌就从一次真实的服务器故障排查经历说起。那是一次线上服务内存缓慢增长最终OOMOut Of Memory的案例。监控图表显示free命令看到的“可用内存”持续下降但通过top或ps查看各个进程的内存占用RSS总和却远远小于已使用的内存。这中间的“差值”去哪了是内存泄漏吗还是内核吃了内存为了彻底搞明白我不得不深入Linux内存管理的底层梳理了从物理内存探测、初始化到内核自身内存布局再到上层应用各种内存分配方式的全链路。这个过程让我意识到如果不理解内存初始化的脉络和不同分配器的适用场景很多内存问题就像隔靴搔痒永远找不到根因。这篇文章我就把自己梳理的这条主线分享出来。我们会从硬件加电后BIOS/UEFI汇报的内存信息开始一步步走过内核启动早期建立的物理内存映射、伙伴系统的诞生、再到为了应对不同大小内存申请而衍生的Slab、kmalloc、vmalloc等机制。最后我们会落到应用层的malloc和brk/mmap系统调用。目标是让你在下次面对内存问题时不仅能看懂/proc/meminfo里每一行数字的含义更能清晰地知道该从哪个分配器、哪个环节去入手排查。无论是做内核开发、驱动编写还是做系统运维、性能优化这套知识体系都至关重要。2. 内存初始化从物理探测到管理框架就绪Linux内核在启动过程中内存管理模块的初始化是重中之重它直接决定了后续整个系统能否稳定、高效地运行。这个过程不是一蹴而就的而是分阶段、分层级逐步构建起来的。2.1 启动早期的物理内存探测与映射在x86体系结构下内核的入口点通常是arch/x86/boot/下的汇编代码。但真正开始建立对物理内存的全面管理是在保护模式切换之后由arch/x86/mm/init.c中的代码主导的。首先内核需要知道“我们有多少可用的物理内存”。这个信息最初来自BIOS或UEFI提供的内存映射E820 map。你可以通过dmesg | grep -i e820或cat /proc/iomem来查看这些信息。内核会解析这些映射区分出哪些是可用内存RAM哪些是保留给硬件设备的如显卡显存哪些是ACPI数据区等。这一步得到的是一个原始的物理内存资源列表。注意这里的“可用”是物理意义上的。一些有硬件缺陷的内存页Bad RAM会在这一步或稍后的内存测试中被标记并排除在外。服务器上遇到因内存硬件故障导致的随机崩溃排查时就可以关注内核启动日志中是否有bad page相关的信息。接下来是建立直接映射区Direct Mapping。这是Linux内核一个非常关键的设计。为了高效访问内存内核需要将物理地址映射到虚拟地址空间。最简单粗暴的方式就是建立一种线性映射让虚拟地址和物理地址只差一个固定的偏移量在x86_64上通常是__PAGE_OFFSET值为0xffff888000000000。这块区域通常被称为“低端内存”的映射区尽管在64位系统上它已经很大了。通过这种映射内核只要用一个简单的宏__pa()和__va()就能在物理地址和虚拟地址间转换效率极高。这个映射是在init_mem_mapping()函数中通过逐步建立页表来完成的。2.2 伙伴系统Buddy System的初始化与作用有了物理内存的映射内核需要一种方法来管理这些离散的物理页帧Page Frame以应对后续各种大小不一的内存申请。这就是伙伴系统登场的时刻。它是Linux物理内存管理的核心分配器负责管理连续的物理页框。伙伴系统的初始化发生在mm/page_alloc.c中的free_area_init()系列函数里。它的核心思想是将所有空闲物理内存按照2的幂次方order划分成多个链表free_list。例如order为0对应1页通常4KBorder为1对应2页order为2对应4页以此类推。它的工作原理就像它的名字“伙伴”一样分配当申请2^order个连续页面时系统会在对应order的链表中查找。如果找到直接分配。如果没找到就向更高一级的order比如order1申请一块然后将其对半分裂成两个“伙伴”一个用于分配另一个放入低一级的链表中。释放当释放一块内存时系统会检查它的“伙伴”块是否也空闲且在同一order链表中。如果是就将它们合并成一个更大的块放入更高一级的order链表中。这种合并有助于减少内存碎片。伙伴系统管理的是纯粹的物理页框分配的单位至少是1页4KB。它保证了分配的物理内存是连续的这对于许多硬件设备如DMA控制器和内核自身的数据结构至关重要。你可以通过cat /proc/buddyinfo来查看当前系统各个内存区域Node和不同order下的空闲块数量这是评估外部碎片的一个直观指标。实操心得在内存压力大的服务器上如果/proc/buddyinfo中低order如01的数值很小而高order的数值也为0说明系统物理内存碎片化严重可能难以分配出大的连续物理内存。这常常是某些驱动或应用频繁申请释放大块内存导致的需要考虑调整内存分配策略或使用预留内存memblock reserve。2.3 内存区域ZONE划分与NUMA架构考量物理内存并非铁板一块。由于硬件限制内核需要将物理内存划分为不同的区域ZONE。在x86_64架构下常见的划分有ZONE_DMA用于古老的ISA设备进行DMA操作范围通常是0~16MB。ZONE_DMA32用于32位地址总线的设备进行DMA范围是0~4GB。ZONE_NORMAL内核直接映射区对应的“普通”内存也是内核最常使用的区域。ZONE_HIGHMEM在32位系统上用于映射超过内核直接映射范围的物理内存高端内存。在64位系统上由于虚拟地址空间巨大通常没有这个区域。每个ZONE都有自己的伙伴系统 freelist。分配请求会按照预设的“区域后备列表”zonelist顺序进行尝试例如优先从ZONE_NORMAL分配不够再尝试ZONE_DMA32。对于多处理器服务器NUMA非统一内存访问架构的影响更为关键。在NUMA系统中CPU和它直连的内存组成一个“节点”Node访问本地节点内存的速度远快于访问远端节点内存。内核在初始化时会探测到系统的NUMA拓扑结构为每个节点Node建立上述的内存区域ZONE。伙伴系统、页缓存等都是基于每个Node进行管理的。numactl命令和/proc/zoneinfo、/proc/pagetypeinfo等文件是分析NUMA内存状态的重要工具。踩坑记录我们曾遇到一个数据库服务器性能不稳定的问题。后来发现数据库进程被调度到了Node 0但其大量内存却分配自Node 1导致访问延迟激增。解决方案是使用numactl --cpunodebind0 --membind0来绑定进程的内存和CPU到同一个节点性能立即得到显著提升。理解内存初始化的NUMA划分是优化高性能应用的基础。3. 内核层内存分配方式详解伙伴系统提供了以页为单位的物理内存分配但内核中绝大多数数据结构如task_struct, inode等的大小都远小于一页。如果每次都向伙伴系统申请一整页会造成巨大的内部碎片。为此Linux在伙伴系统之上构建了多层内存分配机制以适应不同大小和特性的需求。3.1 Slab分配器小对象的高速缓存Slab分配器是解决小内存分配和对象复用问题的核心。它的思想是为内核中频繁创建和销毁的特定对象如进程描述符、索引节点对象预先分配好一连串的“后备存储”即Slab。每个Slab由一个或多个连续的物理页组成被分割成一个个等大的对象。Slab分配器包含三个主要层次缓存Cache每个对象类型对应一个缓存如task_struct缓存、inode缓存。缓存管理着多个Slab。Slab缓存中实际分配和释放对象的单位。一个Slab可以处于三种状态满所有对象已分配、部分满、空所有对象空闲。对象ObjectSlab内划分出来的、实际可分配的内存块。当内核需要分配一个inode对象时它直接向inode缓存申请。缓存会从某个部分满或空的Slab中切分出一个空闲对象速度极快。释放时对象被标记为空闲并放回Slab而不是立即归还给伙伴系统这样下次分配时可以直接复用避免了频繁的页分配和初始化开销。你可以通过sudo slabtop命令动态查看各个Slab缓存的使用情况对象数量、内存占用等。/proc/slabinfo文件则提供了更详细的数据。注意事项Slab分配器虽然高效但也会导致“内存被占用却看似空闲”的现象。因为Slab中空闲的对象内存不会被free命令统计为“可用内存”而是算在“内核使用的内存”里。这就是文章开头提到的“差值”的可能原因之一。如果某个缓存的对象大小设计不合理或存在泄漏会导致该缓存不断增长吃掉大量内存。排查时需重点关注slabtop中SIZE和NAME异常的缓存。3.2 kmalloc最常用的通用内核内存分配对于内核中不确定类型、任意大小的内存申请最常用的接口是kmalloc()。它的原型是void *kmalloc(size_t size, gfp_t flags);。kmalloc是基于Slab分配器实现的。内核预先创建了一系列通用大小的Slab缓存称为“size cache”或“kmalloc cache”例如32字节、64字节、128字节……直到较大的如8KB、16KB等。当你调用kmalloc(200, GFP_KERNEL)时内核会向上取整到最近的标准大小比如256字节然后从对应的kmalloc-256缓存中分配一个对象。kmalloc有两个关键点分配标志gfp_t flags这是内存分配行为的控制字。GFP_KERNEL最常用的标志分配可能睡眠触发直接内存回收或页分配适用于进程上下文。GFP_ATOMIC原子分配不会睡眠用于中断上下文、自旋锁保护等不能调度的场景。优先级高但可能因内存不足而失败。GFP_DMA指定从ZONE_DMA区域分配用于DMA设备。__GFP_ZERO分配后将内存清零。物理连续性kmalloc保证返回的虚拟地址对应的物理内存是连续的。这是因为它底层是从伙伴系统分配的页再交给Slab管理。因此它适用于需要物理连续内存的场景比如设备驱动中准备DMA缓冲区如果大小不超过一页可以用kmalloc更大的则需要其他方式。3.3 vmalloc大块虚拟连续内存的分配与kmalloc相反vmalloc()申请的内存其虚拟地址空间是连续的但物理页框可以是离散的。它通过修改页表将一系列不连续的物理页映射到一段连续的虚拟地址范围。vmalloc的工作流程是在虚拟地址空间的vmalloc区域位于内核空间的高地址处找出一段足够大的连续虚拟区间。向伙伴系统申请多个单独的物理页框可能来自不同地方。修改页表将这些离散的物理页映射到之前找到的连续虚拟地址上。它的优点是可以分配非常大的虚拟连续内存远大于kmalloc通常能分配的大小后者受限于最大的通用Slab缓存通常不超过128KB且不会对物理内存造成外部碎片压力。缺点是由于物理页不连续并且需要额外建立页表项访问效率低于kmalloc特别是频繁访问时TLB命中率会受影响。因此vmalloc的典型使用场景是内核模块加载时其代码和数据段的内存分配。需要非常大块、但访问不频繁的缓冲区。某些硬件设备的映射需求如果设备支持分散-聚集DMA即Scatter-Gather DMA。3.4 其他专用分配器kvmalloc与percpu除了上述三者内核还有其他针对特定场景的分配器kvmalloc()这是一个“智能”的分配接口。它尝试先用kmalloc分配追求物理连续和速度如果申请的大小超过了kmalloc能处理的范围则自动回退到使用vmalloc。这对于那些不确定申请大小但又希望在小尺寸时获得高性能的代码非常方便。Per-CPU变量这不是传统意义上的内存分配而是一种数据存储策略。它为每个CPU核心都分配一份变量的副本。这样每个CPU访问自己的副本时无需加锁速度极快避免了缓存行伪共享False Sharing问题。常用于计数器、统计量等。通过DEFINE_PER_CPU或alloc_percpu来定义和分配。4. 用户空间内存分配malloc的幕后英雄应用程序开发者最熟悉的malloc、calloc、realloc等函数是C库如glibc提供的用户空间内存分配接口。它们并不是直接的系统调用而是C库在系统调用之上构建的一套复杂的内存管理机制。4.1 brk与mmap系统调用的分工C库的分配器如glibc的ptmalloc2底层主要依赖两个系统调用来向内核“批发”内存brk() / sbrk()通过移动程序的堆顶break指针来扩展或收缩堆内存。堆是一段连续的虚拟地址空间从BSS段结束开始向上增长。brk分配的内存位于这个区域。它的优点是分配和释放合并后的开销小适用于频繁分配释放的小块内存。缺点是容易产生堆碎片且无法释放已分配内存中间的某一部分给操作系统只能从堆顶收缩。mmap()在进程的虚拟地址空间中映射一段新的区域。它可以通过MAP_ANONYMOUS标志创建匿名映射不与任何文件关联纯内存这就是我们常说的“内存映射”分配。mmap分配的内存区域独立于堆彼此隔离。其优点是可以独立释放任意一块映射的内存通过munmap并立即归还给系统适合分配大块内存glibc默认大于128KB的请求会走mmap。缺点是每次mmap/munmap都涉及更复杂的内核操作如查找虚拟地址空间、设置VMA等开销比堆内操作大。glibc的malloc实现综合运用了这两种方式。它维护了一个主分配区使用brk的堆和多个非主分配区使用mmap。对于小内存申请它尝试在堆内通过空闲链表管理对于大内存申请超过M_MMAP_THRESHOLD默认128KB则直接使用mmap。4.2 Glibc malloc的实现策略与优化现代glibc的mallocptmalloc2是一个多线程优化的分配器核心思想是减少锁竞争Per-Thread Arena每个线程可以有自己的“分配区”arena拥有独立的堆内存池。这样线程分配小内存时无需竞争全局锁。可以通过环境变量MALLOC_ARENA_MAX来控制最大arena数量。Bins与Fastbins为了高效管理不同大小的空闲内存块malloc维护了多个链表bins。例如fastbins用于很小且快速分配释放的块small bins和large bins用于管理其他大小的块。这些数据结构是内存碎片和分配速度的关键。Top Chunk堆顶的剩余空间是扩展堆时的备用资源。理解这些机制对调试内存问题很有帮助如果多线程程序malloc竞争激烈可能会创建过多arena导致虚拟地址空间碎片化和内存浪费每个arena都有自己的一小片堆内存。这表现为进程的虚拟内存VSZ很高但实际物理内存RSS没那么高。mallopt()函数或环境变量如MALLOC_MMAP_THRESHOLD_可以调整malloc的行为例如提高mmap的阈值让更多分配发生在堆内可能影响碎片和性能。4.3 用户空间内存视图/proc/pid/maps与smaps如何观察一个进程的内存布局/proc/[pid]/maps文件是终极法宝。它展示了进程整个虚拟地址空间的映射情况每一行代表一个虚拟内存区域VMA包括地址范围权限r-w-x-p文件偏移对文件映射设备号主:次inode号映射的文件路径或区域类型如[heap],[stack],[anon]等。更详细的信息在/proc/[pid]/smaps中它包含了每个VMA的详细统计物理内存占用RSS、私有/共享内存大小、是否脏页、交换分区占用等。这是分析进程内存使用细节、发现内存泄漏观察匿名映射的RSS是否异常增长的黄金标准。排查技巧实录曾经排查一个Java应用内存缓慢增长的问题。top看RSS在涨但堆内存通过jstat看稳定。用pmap -x pid其信息源于/proc/pid/smaps查看发现存在大量64MB左右的匿名映射anon且RSS在持续增加。这指向了Java的堆外内存如Direct ByteBuffer、JNI库分配。最终定位到是某个本地库通过mmap分配了大量缓存且未及时释放。/proc/pid/smaps是定位这类“不知名”内存消耗的利器。5. 高级话题与性能考量理解了基本分配方式后我们还需要关注一些高级特性和性能影响这对于构建高性能、高可靠性的系统至关重要。5.1 内存回收机制页缓存、交换与OOMLinux内存管理的哲学是“尽量利用内存作为缓存”。这就是为什么你总看到free命令中“可用内存”很少但系统运行流畅的原因。未被进程使用的内存会被内核自动用来缓存磁盘数据页缓存Page Cache和文件系统元数据等。当系统需要更多物理页时内核会触发内存回收后台回收kswapd一个内核线程在内存水位低于一定阈值时被唤醒异步地回收页缓存和Slab中的可释放内存。直接回收Direct Reclaim当内存分配请求紧急且空闲内存不足时分配路径会同步地、直接地执行回收。这会导致申请内存的进程被阻塞表现为性能抖动或延迟增加。交换Swapping如果回收干净页缓存后仍不足内核会将一些不活跃的匿名页进程堆、栈数据写入交换分区Swap或交换文件Swapfile以腾出物理内存。频繁交换Swapping会导致严重的性能下降因为磁盘IO速度远慢于内存。当所有回收手段都失败系统彻底无法满足一个关键的内核分配时OOM Killer会被触发。它会根据一套复杂的启发式算法考虑进程的oom_score通常与内存占用、运行时间、优先级等有关选择一个或多个“有罪”的进程杀死以释放内存。可以通过/proc/[pid]/oom_score和oom_score_adj来调整进程被选中的概率。经验之谈对于数据库、缓存等对延迟敏感的服务我们通常希望避免交换和OOM。可以采取以下措施设置/proc/sys/vm/swappiness为一个较低的值如10甚至1让内核更倾向于回收页缓存而不是交换匿名页。但注意设为0在较新内核中并非完全禁用交换。为关键进程设置oom_score_adj为负值如-1000使其免于被OOM Killer选中。确保系统有足够的物理内存并合理设置应用的内存使用上限。5.2 透明大页THP与内存碎片整理现代处理器和操作系统支持大页Huge Page即大于传统4KB的内存页如2MB1GB。使用大页可以带来两大好处减少TLB MissTLB转址旁路缓存容量有限。使用大页意味着一个TLB条目可以覆盖更大的内存范围从而提升地址转换效率对内存访问密集型应用如大型数据库性能提升显著。减少管理开销内核需要管理的页表项数量减少。透明大页Transparent HugePages, THP是内核的一个特性它尝试自动地将符合条件的匿名内存区域如堆、栈背后的普通小页合并成2MB的大页对应用程序透明。可以通过/sys/kernel/mm/transparent_hugepage/enabled控制其行为always,madvise,never。然而THP并非银弹。它的合并和拆分操作称为“内存碎片整理”本身有CPU开销。在内存压力大、碎片化严重的系统上频繁的碎片整理可能导致进程停顿khugepaged内核线程运行或直接回收时的同步整理。我们曾遇到过Java应用因THP导致周期性性能毛刺的案例将其改为madvise模式并由JVM通过-XX:UseTransparentHugePages显式控制后问题解决。5.3 内存cgroup与容器环境下的隔离在容器化环境中内存的隔离和限制是通过内存cgroupmemcg实现的。它为每个控制组设置内存使用上限memory.limit_in_bytes并统计其内存使用情况。memcg的管理层次非常细致包括用户内存进程的RSS、页缓存、Swap使用。内核内存Slab、内核栈等。可以通过memory.kmem.limit_in_bytes单独限制。内存交换分区的总限制。当容器内进程的内存使用超过其cgroup限制时不会立即触发全局的OOM Killer而是会先触发cgroup内部的OOM。内核会在该cgroup内选择一个进程杀死。同时cgroup会进行内存回收包括清理其内的页缓存。理解cgroup的内存统计对于容器运维很重要。memory.usage_in_bytes是当前总使用量memory.stat文件提供了详细的分类统计。有时容器内free命令显示内存充足但容器却因OOM被杀死很可能是因为达到了内核内存kmem的限制而free命令不统计这部分。需要检查memory.kmem.usage_in_bytes。6. 实战内存问题排查工具箱与思路掌握了原理最终要落到解决问题上。这里梳理一套排查Linux内存问题的通用思路和工具链。6.1 监控与初步诊断从free到/proc/meminfo第一步永远是看整体情况free -h快速查看内存总量、使用量、缓冲/缓存、可用量。重点关注available列估算可用于新进程的内存考虑了可回收的缓存它比free列更有参考价值。cat /proc/meminfo这是所有内存信息的源头。关键字段MemTotal,MemFree,MemAvailableBuffers,Cached页缓存的一部分。SlabSlab分配器总占用。SReclaimable是可回收的部分如dentry, inode缓存SUnreclaim是不可回收的部分。PageTables页表占用。SwapCached,SwapTotal,SwapFreeAnonPages匿名页堆、栈等。Mapped映射页包括文件映射和匿名映射。KernelStack内核栈占用。VmallocTotal,VmallocUsed,VmallocChunk通过/proc/meminfo你可以初步判断内存用在了哪里是应用进程AnonPages增长是文件缓存Cached增长还是内核数据结构Slab/SUnreclaim增长6.2 进程级内存分析top、ps与/proc/pid/第二步是定位到具体的进程或组件top/htop动态查看进程的RES常驻内存近似RSS、VIRT虚拟内存、SHR共享内存。按M可按内存排序。ps aux --sort-%mem按内存使用率排序查看进程。pmap -x pid基于/proc/pid/smaps展示进程详细的内存映射和RSS占用是定位“内存去哪了”的利器。/proc/pid/status查看进程的VmPeak峰值虚拟内存、VmSize当前虚拟内存、VmRSS物理内存、VmData数据段近似堆、VmStk栈等。/proc/pid/smaps_rollup较新内核提供smaps的汇总信息比解析整个smaps文件更高效。6.3 深入内核分配器slabtop与/proc/buddyinfo如果怀疑问题在内核层sudo slabtop实时查看Slab缓存使用排行。关注OBJS多、SIZE大且持续增长的缓存。cat /proc/slabinfo更详细的Slab信息可用于脚本分析。cat /proc/buddyinfo查看伙伴系统各order的空闲块数判断物理内存外部碎片情况。理想情况是低order数量多高order也有一定数量。cat /proc/pagetypeinfo更详细的内存页类型信息包括迁移类型对分析碎片有帮助。cat /proc/vmallocinfo查看vmalloc分配的区域。6.4 常见内存问题模式与排查路径根据症状可以按以下路径排查系统“可用内存”低但进程RSS总和不高检查/proc/meminfo的Cached和SReclaimable。大概率是文件缓存占用了大量内存这是正常且有益的。可以通过echo 3 /proc/sys/vm/drop_caches临时清理生产环境慎用观察“可用内存”是否回升。检查Slab和SUnreclaim。可能是内核对象泄漏。用slabtop找出可疑缓存。进程RSS持续增长疑似内存泄漏使用pmap或smem定期采样该进程的内存映射观察哪个VMA的RSS在持续增长特别是[anon]区域。如果是Java进程结合jcmd pid VM.native_memory或jmap分析堆外内存。如果是C/C程序使用Valgrind的memcheck工具或gperftools的heap profiler进行检测。系统响应变慢可能发生交换使用vmstat 1或sar -B 1查看siswap in和soswap out列确认是否有持续的交换活动。使用cat /proc/meminfo | grep Swap查看交换分区使用量。使用iotop查看是否kswapd进程的IO很高。进程被OOM Killer杀死查看内核日志dmesg | tail -50寻找Out of memory或Killed process信息。日志会记录被杀进程的pid、名称、oom_score以及当时的内存概况。分析被杀进程的内存使用模式检查是否设置了不合理的cgroup内存限制。内存管理是Linux系统最复杂的子系统之一但它的设计充满了智慧。从底层的伙伴系统管理物理连续性到Slab优化小对象分配再到vmalloc提供虚拟连续性最后到用户空间malloc的巧妙平衡每一层都在解决特定场景下的效率与碎片问题。理解这条链路不仅能让你在出现问题时快速定位更能让你在设计和开发软件时做出更明智的内存使用决策。比如在驱动中分配DMA缓冲区该用kmalloc还是dma_alloc_coherent在用户空间何时该用malloc何时该考虑自定义内存池或直接使用mmap这些选择背后都是对这套内存管理体系理解的深度体现。
Linux内存管理全景解析：从伙伴系统到malloc的完整链路
发布时间：2026/5/21 7:19:42
1. 项目概述从开机到应用Linux内存管理的全景图刚接触Linux内核开发或者系统调优的朋友经常会听到“伙伴系统”、“Slab分配器”、“vmalloc”这些名词感觉它们既神秘又分散。实际上这些概念串联起来就是Linux操作系统从按下电源键那一刻起到你的应用程序成功申请到一块内存的完整故事。今天我们不谈枯燥的理论堆砌就从一次真实的服务器故障排查经历说起。那是一次线上服务内存缓慢增长最终OOMOut Of Memory的案例。监控图表显示free命令看到的“可用内存”持续下降但通过top或ps查看各个进程的内存占用RSS总和却远远小于已使用的内存。这中间的“差值”去哪了是内存泄漏吗还是内核吃了内存为了彻底搞明白我不得不深入Linux内存管理的底层梳理了从物理内存探测、初始化到内核自身内存布局再到上层应用各种内存分配方式的全链路。这个过程让我意识到如果不理解内存初始化的脉络和不同分配器的适用场景很多内存问题就像隔靴搔痒永远找不到根因。这篇文章我就把自己梳理的这条主线分享出来。我们会从硬件加电后BIOS/UEFI汇报的内存信息开始一步步走过内核启动早期建立的物理内存映射、伙伴系统的诞生、再到为了应对不同大小内存申请而衍生的Slab、kmalloc、vmalloc等机制。最后我们会落到应用层的malloc和brk/mmap系统调用。目标是让你在下次面对内存问题时不仅能看懂/proc/meminfo里每一行数字的含义更能清晰地知道该从哪个分配器、哪个环节去入手排查。无论是做内核开发、驱动编写还是做系统运维、性能优化这套知识体系都至关重要。2. 内存初始化从物理探测到管理框架就绪Linux内核在启动过程中内存管理模块的初始化是重中之重它直接决定了后续整个系统能否稳定、高效地运行。这个过程不是一蹴而就的而是分阶段、分层级逐步构建起来的。2.1 启动早期的物理内存探测与映射在x86体系结构下内核的入口点通常是arch/x86/boot/下的汇编代码。但真正开始建立对物理内存的全面管理是在保护模式切换之后由arch/x86/mm/init.c中的代码主导的。首先内核需要知道“我们有多少可用的物理内存”。这个信息最初来自BIOS或UEFI提供的内存映射E820 map。你可以通过dmesg | grep -i e820或cat /proc/iomem来查看这些信息。内核会解析这些映射区分出哪些是可用内存RAM哪些是保留给硬件设备的如显卡显存哪些是ACPI数据区等。这一步得到的是一个原始的物理内存资源列表。注意这里的“可用”是物理意义上的。一些有硬件缺陷的内存页Bad RAM会在这一步或稍后的内存测试中被标记并排除在外。服务器上遇到因内存硬件故障导致的随机崩溃排查时就可以关注内核启动日志中是否有bad page相关的信息。接下来是建立直接映射区Direct Mapping。这是Linux内核一个非常关键的设计。为了高效访问内存内核需要将物理地址映射到虚拟地址空间。最简单粗暴的方式就是建立一种线性映射让虚拟地址和物理地址只差一个固定的偏移量在x86_64上通常是__PAGE_OFFSET值为0xffff888000000000。这块区域通常被称为“低端内存”的映射区尽管在64位系统上它已经很大了。通过这种映射内核只要用一个简单的宏__pa()和__va()就能在物理地址和虚拟地址间转换效率极高。这个映射是在init_mem_mapping()函数中通过逐步建立页表来完成的。2.2 伙伴系统Buddy System的初始化与作用有了物理内存的映射内核需要一种方法来管理这些离散的物理页帧Page Frame以应对后续各种大小不一的内存申请。这就是伙伴系统登场的时刻。它是Linux物理内存管理的核心分配器负责管理连续的物理页框。伙伴系统的初始化发生在mm/page_alloc.c中的free_area_init()系列函数里。它的核心思想是将所有空闲物理内存按照2的幂次方order划分成多个链表free_list。例如order为0对应1页通常4KBorder为1对应2页order为2对应4页以此类推。它的工作原理就像它的名字“伙伴”一样分配当申请2^order个连续页面时系统会在对应order的链表中查找。如果找到直接分配。如果没找到就向更高一级的order比如order1申请一块然后将其对半分裂成两个“伙伴”一个用于分配另一个放入低一级的链表中。释放当释放一块内存时系统会检查它的“伙伴”块是否也空闲且在同一order链表中。如果是就将它们合并成一个更大的块放入更高一级的order链表中。这种合并有助于减少内存碎片。伙伴系统管理的是纯粹的物理页框分配的单位至少是1页4KB。它保证了分配的物理内存是连续的这对于许多硬件设备如DMA控制器和内核自身的数据结构至关重要。你可以通过cat /proc/buddyinfo来查看当前系统各个内存区域Node和不同order下的空闲块数量这是评估外部碎片的一个直观指标。实操心得在内存压力大的服务器上如果/proc/buddyinfo中低order如01的数值很小而高order的数值也为0说明系统物理内存碎片化严重可能难以分配出大的连续物理内存。这常常是某些驱动或应用频繁申请释放大块内存导致的需要考虑调整内存分配策略或使用预留内存memblock reserve。2.3 内存区域ZONE划分与NUMA架构考量物理内存并非铁板一块。由于硬件限制内核需要将物理内存划分为不同的区域ZONE。在x86_64架构下常见的划分有ZONE_DMA用于古老的ISA设备进行DMA操作范围通常是0~16MB。ZONE_DMA32用于32位地址总线的设备进行DMA范围是0~4GB。ZONE_NORMAL内核直接映射区对应的“普通”内存也是内核最常使用的区域。ZONE_HIGHMEM在32位系统上用于映射超过内核直接映射范围的物理内存高端内存。在64位系统上由于虚拟地址空间巨大通常没有这个区域。每个ZONE都有自己的伙伴系统 freelist。分配请求会按照预设的“区域后备列表”zonelist顺序进行尝试例如优先从ZONE_NORMAL分配不够再尝试ZONE_DMA32。对于多处理器服务器NUMA非统一内存访问架构的影响更为关键。在NUMA系统中CPU和它直连的内存组成一个“节点”Node访问本地节点内存的速度远快于访问远端节点内存。内核在初始化时会探测到系统的NUMA拓扑结构为每个节点Node建立上述的内存区域ZONE。伙伴系统、页缓存等都是基于每个Node进行管理的。numactl命令和/proc/zoneinfo、/proc/pagetypeinfo等文件是分析NUMA内存状态的重要工具。踩坑记录我们曾遇到一个数据库服务器性能不稳定的问题。后来发现数据库进程被调度到了Node 0但其大量内存却分配自Node 1导致访问延迟激增。解决方案是使用numactl --cpunodebind0 --membind0来绑定进程的内存和CPU到同一个节点性能立即得到显著提升。理解内存初始化的NUMA划分是优化高性能应用的基础。3. 内核层内存分配方式详解伙伴系统提供了以页为单位的物理内存分配但内核中绝大多数数据结构如task_struct, inode等的大小都远小于一页。如果每次都向伙伴系统申请一整页会造成巨大的内部碎片。为此Linux在伙伴系统之上构建了多层内存分配机制以适应不同大小和特性的需求。3.1 Slab分配器小对象的高速缓存Slab分配器是解决小内存分配和对象复用问题的核心。它的思想是为内核中频繁创建和销毁的特定对象如进程描述符、索引节点对象预先分配好一连串的“后备存储”即Slab。每个Slab由一个或多个连续的物理页组成被分割成一个个等大的对象。Slab分配器包含三个主要层次缓存Cache每个对象类型对应一个缓存如task_struct缓存、inode缓存。缓存管理着多个Slab。Slab缓存中实际分配和释放对象的单位。一个Slab可以处于三种状态满所有对象已分配、部分满、空所有对象空闲。对象ObjectSlab内划分出来的、实际可分配的内存块。当内核需要分配一个inode对象时它直接向inode缓存申请。缓存会从某个部分满或空的Slab中切分出一个空闲对象速度极快。释放时对象被标记为空闲并放回Slab而不是立即归还给伙伴系统这样下次分配时可以直接复用避免了频繁的页分配和初始化开销。你可以通过sudo slabtop命令动态查看各个Slab缓存的使用情况对象数量、内存占用等。/proc/slabinfo文件则提供了更详细的数据。注意事项Slab分配器虽然高效但也会导致“内存被占用却看似空闲”的现象。因为Slab中空闲的对象内存不会被free命令统计为“可用内存”而是算在“内核使用的内存”里。这就是文章开头提到的“差值”的可能原因之一。如果某个缓存的对象大小设计不合理或存在泄漏会导致该缓存不断增长吃掉大量内存。排查时需重点关注slabtop中SIZE和NAME异常的缓存。3.2 kmalloc最常用的通用内核内存分配对于内核中不确定类型、任意大小的内存申请最常用的接口是kmalloc()。它的原型是void *kmalloc(size_t size, gfp_t flags);。kmalloc是基于Slab分配器实现的。内核预先创建了一系列通用大小的Slab缓存称为“size cache”或“kmalloc cache”例如32字节、64字节、128字节……直到较大的如8KB、16KB等。当你调用kmalloc(200, GFP_KERNEL)时内核会向上取整到最近的标准大小比如256字节然后从对应的kmalloc-256缓存中分配一个对象。kmalloc有两个关键点分配标志gfp_t flags这是内存分配行为的控制字。GFP_KERNEL最常用的标志分配可能睡眠触发直接内存回收或页分配适用于进程上下文。GFP_ATOMIC原子分配不会睡眠用于中断上下文、自旋锁保护等不能调度的场景。优先级高但可能因内存不足而失败。GFP_DMA指定从ZONE_DMA区域分配用于DMA设备。__GFP_ZERO分配后将内存清零。物理连续性kmalloc保证返回的虚拟地址对应的物理内存是连续的。这是因为它底层是从伙伴系统分配的页再交给Slab管理。因此它适用于需要物理连续内存的场景比如设备驱动中准备DMA缓冲区如果大小不超过一页可以用kmalloc更大的则需要其他方式。3.3 vmalloc大块虚拟连续内存的分配与kmalloc相反vmalloc()申请的内存其虚拟地址空间是连续的但物理页框可以是离散的。它通过修改页表将一系列不连续的物理页映射到一段连续的虚拟地址范围。vmalloc的工作流程是在虚拟地址空间的vmalloc区域位于内核空间的高地址处找出一段足够大的连续虚拟区间。向伙伴系统申请多个单独的物理页框可能来自不同地方。修改页表将这些离散的物理页映射到之前找到的连续虚拟地址上。它的优点是可以分配非常大的虚拟连续内存远大于kmalloc通常能分配的大小后者受限于最大的通用Slab缓存通常不超过128KB且不会对物理内存造成外部碎片压力。缺点是由于物理页不连续并且需要额外建立页表项访问效率低于kmalloc特别是频繁访问时TLB命中率会受影响。因此vmalloc的典型使用场景是内核模块加载时其代码和数据段的内存分配。需要非常大块、但访问不频繁的缓冲区。某些硬件设备的映射需求如果设备支持分散-聚集DMA即Scatter-Gather DMA。3.4 其他专用分配器kvmalloc与percpu除了上述三者内核还有其他针对特定场景的分配器kvmalloc()这是一个“智能”的分配接口。它尝试先用kmalloc分配追求物理连续和速度如果申请的大小超过了kmalloc能处理的范围则自动回退到使用vmalloc。这对于那些不确定申请大小但又希望在小尺寸时获得高性能的代码非常方便。Per-CPU变量这不是传统意义上的内存分配而是一种数据存储策略。它为每个CPU核心都分配一份变量的副本。这样每个CPU访问自己的副本时无需加锁速度极快避免了缓存行伪共享False Sharing问题。常用于计数器、统计量等。通过DEFINE_PER_CPU或alloc_percpu来定义和分配。4. 用户空间内存分配malloc的幕后英雄应用程序开发者最熟悉的malloc、calloc、realloc等函数是C库如glibc提供的用户空间内存分配接口。它们并不是直接的系统调用而是C库在系统调用之上构建的一套复杂的内存管理机制。4.1 brk与mmap系统调用的分工C库的分配器如glibc的ptmalloc2底层主要依赖两个系统调用来向内核“批发”内存brk() / sbrk()通过移动程序的堆顶break指针来扩展或收缩堆内存。堆是一段连续的虚拟地址空间从BSS段结束开始向上增长。brk分配的内存位于这个区域。它的优点是分配和释放合并后的开销小适用于频繁分配释放的小块内存。缺点是容易产生堆碎片且无法释放已分配内存中间的某一部分给操作系统只能从堆顶收缩。mmap()在进程的虚拟地址空间中映射一段新的区域。它可以通过MAP_ANONYMOUS标志创建匿名映射不与任何文件关联纯内存这就是我们常说的“内存映射”分配。mmap分配的内存区域独立于堆彼此隔离。其优点是可以独立释放任意一块映射的内存通过munmap并立即归还给系统适合分配大块内存glibc默认大于128KB的请求会走mmap。缺点是每次mmap/munmap都涉及更复杂的内核操作如查找虚拟地址空间、设置VMA等开销比堆内操作大。glibc的malloc实现综合运用了这两种方式。它维护了一个主分配区使用brk的堆和多个非主分配区使用mmap。对于小内存申请它尝试在堆内通过空闲链表管理对于大内存申请超过M_MMAP_THRESHOLD默认128KB则直接使用mmap。4.2 Glibc malloc的实现策略与优化现代glibc的mallocptmalloc2是一个多线程优化的分配器核心思想是减少锁竞争Per-Thread Arena每个线程可以有自己的“分配区”arena拥有独立的堆内存池。这样线程分配小内存时无需竞争全局锁。可以通过环境变量MALLOC_ARENA_MAX来控制最大arena数量。Bins与Fastbins为了高效管理不同大小的空闲内存块malloc维护了多个链表bins。例如fastbins用于很小且快速分配释放的块small bins和large bins用于管理其他大小的块。这些数据结构是内存碎片和分配速度的关键。Top Chunk堆顶的剩余空间是扩展堆时的备用资源。理解这些机制对调试内存问题很有帮助如果多线程程序malloc竞争激烈可能会创建过多arena导致虚拟地址空间碎片化和内存浪费每个arena都有自己的一小片堆内存。这表现为进程的虚拟内存VSZ很高但实际物理内存RSS没那么高。mallopt()函数或环境变量如MALLOC_MMAP_THRESHOLD_可以调整malloc的行为例如提高mmap的阈值让更多分配发生在堆内可能影响碎片和性能。4.3 用户空间内存视图/proc/pid/maps与smaps如何观察一个进程的内存布局/proc/[pid]/maps文件是终极法宝。它展示了进程整个虚拟地址空间的映射情况每一行代表一个虚拟内存区域VMA包括地址范围权限r-w-x-p文件偏移对文件映射设备号主:次inode号映射的文件路径或区域类型如[heap],[stack],[anon]等。更详细的信息在/proc/[pid]/smaps中它包含了每个VMA的详细统计物理内存占用RSS、私有/共享内存大小、是否脏页、交换分区占用等。这是分析进程内存使用细节、发现内存泄漏观察匿名映射的RSS是否异常增长的黄金标准。排查技巧实录曾经排查一个Java应用内存缓慢增长的问题。top看RSS在涨但堆内存通过jstat看稳定。用pmap -x pid其信息源于/proc/pid/smaps查看发现存在大量64MB左右的匿名映射anon且RSS在持续增加。这指向了Java的堆外内存如Direct ByteBuffer、JNI库分配。最终定位到是某个本地库通过mmap分配了大量缓存且未及时释放。/proc/pid/smaps是定位这类“不知名”内存消耗的利器。5. 高级话题与性能考量理解了基本分配方式后我们还需要关注一些高级特性和性能影响这对于构建高性能、高可靠性的系统至关重要。5.1 内存回收机制页缓存、交换与OOMLinux内存管理的哲学是“尽量利用内存作为缓存”。这就是为什么你总看到free命令中“可用内存”很少但系统运行流畅的原因。未被进程使用的内存会被内核自动用来缓存磁盘数据页缓存Page Cache和文件系统元数据等。当系统需要更多物理页时内核会触发内存回收后台回收kswapd一个内核线程在内存水位低于一定阈值时被唤醒异步地回收页缓存和Slab中的可释放内存。直接回收Direct Reclaim当内存分配请求紧急且空闲内存不足时分配路径会同步地、直接地执行回收。这会导致申请内存的进程被阻塞表现为性能抖动或延迟增加。交换Swapping如果回收干净页缓存后仍不足内核会将一些不活跃的匿名页进程堆、栈数据写入交换分区Swap或交换文件Swapfile以腾出物理内存。频繁交换Swapping会导致严重的性能下降因为磁盘IO速度远慢于内存。当所有回收手段都失败系统彻底无法满足一个关键的内核分配时OOM Killer会被触发。它会根据一套复杂的启发式算法考虑进程的oom_score通常与内存占用、运行时间、优先级等有关选择一个或多个“有罪”的进程杀死以释放内存。可以通过/proc/[pid]/oom_score和oom_score_adj来调整进程被选中的概率。经验之谈对于数据库、缓存等对延迟敏感的服务我们通常希望避免交换和OOM。可以采取以下措施设置/proc/sys/vm/swappiness为一个较低的值如10甚至1让内核更倾向于回收页缓存而不是交换匿名页。但注意设为0在较新内核中并非完全禁用交换。为关键进程设置oom_score_adj为负值如-1000使其免于被OOM Killer选中。确保系统有足够的物理内存并合理设置应用的内存使用上限。5.2 透明大页THP与内存碎片整理现代处理器和操作系统支持大页Huge Page即大于传统4KB的内存页如2MB1GB。使用大页可以带来两大好处减少TLB MissTLB转址旁路缓存容量有限。使用大页意味着一个TLB条目可以覆盖更大的内存范围从而提升地址转换效率对内存访问密集型应用如大型数据库性能提升显著。减少管理开销内核需要管理的页表项数量减少。透明大页Transparent HugePages, THP是内核的一个特性它尝试自动地将符合条件的匿名内存区域如堆、栈背后的普通小页合并成2MB的大页对应用程序透明。可以通过/sys/kernel/mm/transparent_hugepage/enabled控制其行为always,madvise,never。然而THP并非银弹。它的合并和拆分操作称为“内存碎片整理”本身有CPU开销。在内存压力大、碎片化严重的系统上频繁的碎片整理可能导致进程停顿khugepaged内核线程运行或直接回收时的同步整理。我们曾遇到过Java应用因THP导致周期性性能毛刺的案例将其改为madvise模式并由JVM通过-XX:UseTransparentHugePages显式控制后问题解决。5.3 内存cgroup与容器环境下的隔离在容器化环境中内存的隔离和限制是通过内存cgroupmemcg实现的。它为每个控制组设置内存使用上限memory.limit_in_bytes并统计其内存使用情况。memcg的管理层次非常细致包括用户内存进程的RSS、页缓存、Swap使用。内核内存Slab、内核栈等。可以通过memory.kmem.limit_in_bytes单独限制。内存交换分区的总限制。当容器内进程的内存使用超过其cgroup限制时不会立即触发全局的OOM Killer而是会先触发cgroup内部的OOM。内核会在该cgroup内选择一个进程杀死。同时cgroup会进行内存回收包括清理其内的页缓存。理解cgroup的内存统计对于容器运维很重要。memory.usage_in_bytes是当前总使用量memory.stat文件提供了详细的分类统计。有时容器内free命令显示内存充足但容器却因OOM被杀死很可能是因为达到了内核内存kmem的限制而free命令不统计这部分。需要检查memory.kmem.usage_in_bytes。6. 实战内存问题排查工具箱与思路掌握了原理最终要落到解决问题上。这里梳理一套排查Linux内存问题的通用思路和工具链。6.1 监控与初步诊断从free到/proc/meminfo第一步永远是看整体情况free -h快速查看内存总量、使用量、缓冲/缓存、可用量。重点关注available列估算可用于新进程的内存考虑了可回收的缓存它比free列更有参考价值。cat /proc/meminfo这是所有内存信息的源头。关键字段MemTotal,MemFree,MemAvailableBuffers,Cached页缓存的一部分。SlabSlab分配器总占用。SReclaimable是可回收的部分如dentry, inode缓存SUnreclaim是不可回收的部分。PageTables页表占用。SwapCached,SwapTotal,SwapFreeAnonPages匿名页堆、栈等。Mapped映射页包括文件映射和匿名映射。KernelStack内核栈占用。VmallocTotal,VmallocUsed,VmallocChunk通过/proc/meminfo你可以初步判断内存用在了哪里是应用进程AnonPages增长是文件缓存Cached增长还是内核数据结构Slab/SUnreclaim增长6.2 进程级内存分析top、ps与/proc/pid/第二步是定位到具体的进程或组件top/htop动态查看进程的RES常驻内存近似RSS、VIRT虚拟内存、SHR共享内存。按M可按内存排序。ps aux --sort-%mem按内存使用率排序查看进程。pmap -x pid基于/proc/pid/smaps展示进程详细的内存映射和RSS占用是定位“内存去哪了”的利器。/proc/pid/status查看进程的VmPeak峰值虚拟内存、VmSize当前虚拟内存、VmRSS物理内存、VmData数据段近似堆、VmStk栈等。/proc/pid/smaps_rollup较新内核提供smaps的汇总信息比解析整个smaps文件更高效。6.3 深入内核分配器slabtop与/proc/buddyinfo如果怀疑问题在内核层sudo slabtop实时查看Slab缓存使用排行。关注OBJS多、SIZE大且持续增长的缓存。cat /proc/slabinfo更详细的Slab信息可用于脚本分析。cat /proc/buddyinfo查看伙伴系统各order的空闲块数判断物理内存外部碎片情况。理想情况是低order数量多高order也有一定数量。cat /proc/pagetypeinfo更详细的内存页类型信息包括迁移类型对分析碎片有帮助。cat /proc/vmallocinfo查看vmalloc分配的区域。6.4 常见内存问题模式与排查路径根据症状可以按以下路径排查系统“可用内存”低但进程RSS总和不高检查/proc/meminfo的Cached和SReclaimable。大概率是文件缓存占用了大量内存这是正常且有益的。可以通过echo 3 /proc/sys/vm/drop_caches临时清理生产环境慎用观察“可用内存”是否回升。检查Slab和SUnreclaim。可能是内核对象泄漏。用slabtop找出可疑缓存。进程RSS持续增长疑似内存泄漏使用pmap或smem定期采样该进程的内存映射观察哪个VMA的RSS在持续增长特别是[anon]区域。如果是Java进程结合jcmd pid VM.native_memory或jmap分析堆外内存。如果是C/C程序使用Valgrind的memcheck工具或gperftools的heap profiler进行检测。系统响应变慢可能发生交换使用vmstat 1或sar -B 1查看siswap in和soswap out列确认是否有持续的交换活动。使用cat /proc/meminfo | grep Swap查看交换分区使用量。使用iotop查看是否kswapd进程的IO很高。进程被OOM Killer杀死查看内核日志dmesg | tail -50寻找Out of memory或Killed process信息。日志会记录被杀进程的pid、名称、oom_score以及当时的内存概况。分析被杀进程的内存使用模式检查是否设置了不合理的cgroup内存限制。内存管理是Linux系统最复杂的子系统之一但它的设计充满了智慧。从底层的伙伴系统管理物理连续性到Slab优化小对象分配再到vmalloc提供虚拟连续性最后到用户空间malloc的巧妙平衡每一层都在解决特定场景下的效率与碎片问题。理解这条链路不仅能让你在出现问题时快速定位更能让你在设计和开发软件时做出更明智的内存使用决策。比如在驱动中分配DMA缓冲区该用kmalloc还是dma_alloc_coherent在用户空间何时该用malloc何时该考虑自定义内存池或直接使用mmap这些选择背后都是对这套内存管理体系理解的深度体现。
