上周一个朋友给我发来一段dmesg说他们的视频处理服务连续跑三天必出一次“page allocation failure”卡死前内存明明还剩30%。我让他把/proc/buddyinfo贴出来果然order-4以上全部为0。这已经不是第一次见这种问题了内存总量充足但硬件要的“连续”拿不出来。做内存管理优化如果只盯着虚拟内存、malloc/free永远差一层真正的裁判是硬件——MMU、TLB、DRAM bank、cache line、DMA控制器每一个都在用自己的规则检验你的内存布局。下面我就从硬件视角把排查内存碎片问题的完整思路整理一遍包括原理、实操命令和工程手段希望对写C/C服务、做嵌入式Linux、以及搞性能优化的朋友有用。1. 硬件眼中的地址虚拟地址、物理地址与页表如何参与碎片化1.1 你手里的指针是“座位号”不是“座位本身”很多做C/C的朋友有个惯性误区malloc返回一个地址就以为这块内存“已经有了”。在现代操作系统和带MMU的硬件上这个地址只是虚拟地址真正落到哪块物理内存是你在第一次写入或读取时由CPU触发缺页异常、内核分配物理页后才确定的。换成一个生活化的比喻虚拟地址是电影票上的座位号物理页才是影厅里那把真实的椅子。你拿着票进场票面印刷很漂亮但座位是不是连着的、周围坐没坐满陌生人得等检票那一刻才知道。这个模型决定了碎片问题的本质用户态看到的内存是“虚拟空间”里的连续地址物理内存是不是连续用户态根本感知不到直到某次需要大量物理连续内存的操作失败比如DMA映射、大页分配、巨型网络包处理你才会被现实扇一巴掌。更麻烦的是硬件视角下“连续”不是软概念CPU拿到一个虚拟地址要通过多级页表翻译成物理地址翻译失败就去缺页翻译成功后访问cachecache miss后交给内存控制器访问DRAM。整条链路里任何一环因为物理页过于分散而变慢都会直接体现在程序延迟上。1.2 地址粒度页(Page)是硬件认识的“最小单位”把物理内存切成固定大小的小块来管理是所有现代操作系统的基本玩法Linux默认4KB一页。为什么要按页切因为CPU的MMU只认这个粒度TLB缓存的是“虚拟页号→物理页号”的映射页表里每一项也对应一页。页的大小一旦固定物理连续性的要求就变成你要找的是一块由2的幂次个页组成的连续区域。这里要理解一个关键点虚拟地址连续不代表物理页连续。比如你malloc了1MB内核可能给你256个分散的4KB物理页。对普通CPU访问来说没问题因为MMU帮你翻译。但对于DMA、对于单次映射容量有限的硬件设备这是致命的。硬件层面看“碎片化”更精确的定义是物理内存中满足某种对齐和大小的连续空闲块数量不足。分配器要保证返回的起始地址按2的幂次对齐设备驱动经常要order-8甚至order-10的块。碎片越多这种块越稀罕。1.3 TLB碎片越多地址翻译越贵TLB是CPU内部容量很有限的缓存一般只有几十到几百个条目。它的作用是记住最近用过的虚拟页到物理页的映射避免每次访问都去内存查页表。TLB能覆盖的内存范围 条目数 × 页大小。假设CPU有64个L1 TLB条目用4KB小页只能覆盖256KB一旦你的工作集超过这个范围每访问几个新页面就会触发一次TLB MissCPU需要走到多级页表去逐级查。这就是碎片和硬件性能最直接的交汇点碎片妨碍了大页的使用。Linux的THP、HugeTLB需要2MB甚至1GB大小的物理连续页碎片严重时申请不到内核被迫退回4KB小页。同样的内存规模用4KB页需要的TLB条目数是用2MB大页的512倍。在我实测的一个Java服务场景里堆内存8GB启用THP前后TLB Miss从每千指令几十次降到个位数整机吞吐提升了约15%。别觉得15%不多在低延迟场景这可能就是超时率从千分之一涨到百分之三的差距。而碎片正是让THP失效的幕后推手。后来给一个Julia数值计算程序做性能优化时也遇到类似情况计算数组的存储布局一旦被打散TLB开销能直接让矩阵运算掉一半效率。2. DRAM内存控制器视角碎片化如何悄悄拖垮访问性能2.1 内存不是一块“大数组”是三维结构bank、row、column很多程序员把DRAM想象成一个大数组地址递增就是顺序读。真实情况是DDR颗粒内部划分成多个bank每个bank有一排row缓冲也叫行缓冲区。内存控制器访问一次数据得先激活目标rowACT命令然后在row缓冲里读写目标column如果下次访问落在同一个bank的另一个row就必须先把当前行写回Precharge再激活新行。这个“行冲突”的操作代价非常大。举一组典型参数DDR4-3200的tRCD大约13~15nstRAS约32nstRC约45ns。如果连续访问的地址恰好落在不同的row上每次都要处理行冲突延迟从几十ns飙升到百ns级别。反过来如果访问模式是顺序的同一个row里的连续burst基本都能命中行缓冲延迟低很多。碎片化的进程它的活跃内存页在物理上混乱散布内存控制器看到的就是一批又一批互不相邻的地址——这边的bank在activate那边的bank在precharge硬件预取器也失效带宽和延迟同时恶化。我在压力测试机上对比过同一程序内存布局顺序和打散后内存带宽下降20%~50%很常见。2.2 Cache Line层面的“邻居互害”伪共享和预取失效再往下到CPU缓存粒度。Cache Line通常是64字节物理相邻地址会被加载到同一个cache line。碎片化分配可能导致两个线程各自频繁写的变量被分到了同一个cache line里。两个核心同时写这个lineMESI协议会让这个line在两个核之间来回失效、重写这就是伪共享。一次伪共享触发可能出现几十到几百个时钟周期的开销而且完全隐藏在你的业务代码逻辑之外是最难查的那类性能问题。另一个容易被忽略的点是硬件预取器。现代CPU会观察顺序访问模式提前把后面128B、256B的内容拉进cache。前提是你访问的物理地址确实是连续或按固定步长递增。碎片化的物理布局会让逻辑上连续的buffer实际上东一块西一块预取器几乎每次都在猜错预取进来的数据很多用不上cache的有效命中率也会被稀释。2.3 DMA与硬件加速器场景物理连续是“刚需”而非“优化项”如果说CPU还能靠MMU帮你掩盖碎片问题那DMA就是压垮骆驼的最后一根稻草。网卡、NVMe控制器、USB控制器、GPU、DSP在做数据传输时走的是物理地址。如果平台没有IOMMU/SMMU做地址翻译驱动就必须拿到物理连续的缓冲区。碎片严重时驱动申请高order页面失败设备就报DMA error、ring buffer分配失败甚至直接crash。在嵌入式Linux上做视频采集或音频处理的朋友大概率见过CMA: cma_alloc: failed这种日志。CMA是一块预留的连续内存池平时允许Movable页面占用需要时把页面迁走再分配连续块。但当系统里全是长时间不挪动的匿名页或不可移动页时CMA分配照样失败。我自己维护的一个采集模块最初用kmalloc分配大块跑两三天后稳定复现DMA失败改成从CMA池分配并配合mlock固定关键页面后问题消除了。这里想强调的是硬件不关心你软件里有多少剩余内存它只认“给不给我一段连续物理地址”。3. 从Linux分配器看硬件妥协Buddy、SLAB、大页和CMA的真实取舍3.1 Buddy系统按2的幂切蛋糕外碎片的根源Linux物理内存分配的核心是Buddy System。它把空闲页按2的幂次分成不同order的块低order的块可以由相邻伙伴合并成高order高order块也能拆成低order用。这本来是为平衡分配效率与碎片率设计的但有一个先天问题外碎片。当内存中散布着大量不可移动的小块时低order块永远合并不成高order块虽然总量充足但order-8、order-10这种大片区域就是凑不出来。查看/proc/buddyinfo可以一眼看出系统碎片程度Node 0, zone Normal, 235 452 1080 3 0 0 0 0 0 0 0这一行从order-0到order-10分别是当前zone里每个order的空闲块数。上面例子里order-0有235块order-3有3块再往上全空说明系统能分配的最大连续块只有order-316个页即64KB。如果设备驱动要order-81MB当场失败但free命令看内存可能还剩好几GB。这就是碎片最典型的“总量与连续性背离”。3.2 SLAB/SLUB内碎片的温床物理页分配给内核后还需要细分成小对象供数据结构使用这是SLAB家族的活。kmalloc-64、kmalloc-192这类size class会从连续页里切成固定尺寸的小对象。问题是一个4KB页如果切成64字节对象理论上放64个但可能有对齐、元数据等损耗最后一小部分空间就废掉了。这属于内碎片分配出去的块内部浪费和外碎片空闲块太碎同属于碎片问题只是藏得更隐蔽。查看/proc/slabinfo能发现系统跑久了之后可能有成百上千个半满的kmalloc slab占用的物理页不少但实际对象利用率很低。很多嵌入式系统跑着跑着发现内存不够追查后发现内核slab占了2GB其中不少是碎片化的slab页。这种情况通常要配合slabinfo和trace定位是哪个内核路径在频繁创建不同size的临时对象。3.3 大页、THP、CMA用硬件特性反制碎片既然碎片让大页难申请Linux给了几个备选方案。HugeTLB是预分配式系统启动时或运行时预留一批2MB/1GB的大页专门给对性能和连续内存敏感的应用。思路是“早申请早安心”把物理连续性问题前置到系统启动阶段避开业务运行后的碎片化。THP则是自动的内核的khugepaged线程在后台扫描尝试把进程里的4KB页合并成2MB大页。如果碎片不严重这个合并能显著降低TLB压力但如果系统已经碎片化合并过程会触发内存规整compaction把大量页面搬来搬去造成CPU尖峰和延迟毛刺。我遇到过一台机器THP开启后业务高峰期每分钟触发一次长达几百毫秒的卡顿就是compaction在搬家。CMA则是DMA场景的保底系统启动时预留一段连续内存平时这段内存可以被Movable页面用于普通分配当驱动需要连续块时内核会把页面迁移走。它把“连续性成本”从静态浪费变成了动态迁移对嵌入式多任务场景很有用。4. 实测定位碎片从page allocation failure到buddyinfo的完整链路4.1 第一现场dmesg里的page allocation failure当内核无法满足某个order的分配时会打印一条page allocation failure日志包含关键信息请求order、gfp_mask、调用栈、当前zone的空闲页统计等。例如myapp: page allocation failure: order:4, mode:0xcc0(GFP_KERNEL) CPU: 2 PID: 1234 Comm: myapp Call Trace: __alloc_pages_nodemask0x... alloc_pages_vma0x... ... Normal: 118*4kB 56*8kB 3*16kB 0*32kB 0*64kB 0*128kB ...从这段日志里我第一眼会看order第二眼看队尾的连续块统计。order-4表示需要16个连续页64KB。日志显示32kB及以上为空说明失败原因不是“没内存”而是“没有连续64KB”。接下来顺着调用栈去查代码路径如果这个分配发生在网卡驱动里基本可以断定是碎片导致DMA buffer申请失败。4.2 /proc/buddyinfo三秒钟看懂碎片水位/proc/buddyinfo是排查碎片的温度计。我习惯用一段简短命令把每行的最大连续order算出来awk /Normal/ {for(i4;iNF;i){ if($i0) maxi-4 }; print max_ordermax} /proc/buddyinfo如果max_order长期低于664KB就属于高危状态低于4基本可以预告近期会出DMA或大页分配问题。建议在服务启动时记录一份baseline之后按小时对比观察碎片趋势。别等到线上故障才开始看那时候日志可能已经覆盖掉了。4.3 是谁在“挡路”page migrate type与长期存活页面Buddy系统把空闲页按迁移类型分成Unmovable、Reclaimable、Movable。Unmovable页不可迁移通常是内核分配、驱动分配Reclaimable页可以回收主要是page cacheMovable页可以迁移主要是用户态匿名页。在高碎片状态下频繁出现order分配失败时/proc/pagetypeinfo能告诉你哪些类型占据了空位、谁是主要阻挡者。更进一步的定位手段是ftrace的mm_page_alloc事件。在长期运行的进程里短暂开启trace就能通过调用栈确认是哪些代码路径不断申请不可移动的高order页。我见过一个case某个驱动每次IO都临时申请order-3用完也不释放时间一长Unmovable块碎成一片把所有order-6以上都卡死了。这种路径用代码评审很难发现必须靠trace数据说话。4.4 一次真实事故复盘视频服务连续运行三天的分配失败拿我去年处理过的一个case举例。一台视频转码服务器C实现跑三天必然出一次page allocation failure (order:4)然后采集线程异常退出。现场数据如下/proc/buddyinfo显示Normal zone order-4及以上全部为0/proc/pagetypeinfo显示Unmovable块在order-0到order-3占据了大量页面用ftrace追踪mm_page_alloc发现大量order-3级别的Unmovable分配来自某个USB摄像头驱动进一步检查驱动源码它在每次打开视频流时用kmalloc申请了128KB的中转buffer并且没有在关闭时释放干净泄漏加碎片共同作用。修复方案分两步驱动改成从固定CMA区域申请buffer并在模块加载时一次性分配、退出时释放应用侧把频繁创建销毁的转码缓冲改成对象池。上线后连续跑了两周buddyinfo稳定dmesg里再没出现过一次分配失败。这个case给我印象最深的是问题表象在内存分配器根因却横跨驱动、业务代码和硬件约束三层缺一层的排查都不完整。5. 工程对抗碎片分配策略、对象池与硬件特性配合的实用方案5.1 原则一把“长命对象”和“短命对象”隔离开碎片化的核心引擎是“长命对象与短命对象交错分配”。长命对象一旦分配往往不可迁移短命对象不断释放会在长命对象之间留下缺口。最优策略是一切长期存活、生命周期和进程一样长的对象在启动阶段就一次性分配好业务运行期尽可能不申请新的常驻大对象。这样留给运行时分配器的地址空间就是“干净”的连续区。对应到代码层就是初始化时把全局缓存、连接池、线程栈、共享内存都建好运行期用内存池来满足小的临时对象。这个原则在嵌入式Linux、C服务、游戏服务端都适用。很多人觉得看pmap虚拟内存量挺正常但物理内存分布平时看不出来真等碎片恶化到影响硬件分配代价就很重了。5.2 原则二用对象池替代频繁malloc/free对象池的思想简单粗暴把同一size class的对象预先分配一批维护一个空闲链表需要时从链表头部拿释放时挂回去。关键点是“绝不还给系统”避免频繁触发内核的页分配和释放。一个按size class分桶的对象池即使不做复杂的内存排序也能拦住90%以上业务代码产生的碎片。写Qt程序的时候尤其注意很多人习惯new一大堆QObject表面是C内存管理问题实际每次new都走一遍malloc对底层碎片的影响通常被忽略。这里有个容易踩的坑对象池里的对象如果跨越多个物理页使用后没有清零下一个使用者假设它是零初始化会读到脏数据。所以池化对象一定要在出池时做强契约要么你有字段标记版本号要么在分配时显式memset。此外池本身也要监控水位长期运行的进程如果池不断增长说明有泄漏别让池变成一个新的泄漏源。5.3 原则三对连续性敏感的资源主动预留如果你的系统里有硬件设备需要连续内存最好在启动阶段就预留到位。几条常用手段echo 64 /proc/sys/vm/nr_hugepages或者用hugetlb的cgroup接口给2MB大页留量设备树里预留reserved-memory/CMA区域确保驱动启动时能拿到连续块对用户态关键buffer调用mlock或mlockall防止被换出同时配合madvise(MADV_HUGEPAGE)引导内核给它们分配大页。预留的本质是“提前锁定物理资源”牺牲一部分弹性换硬件功能的稳定性。在一致性要求很高的产品里这是很划算的交易尤其是嵌入式硬件资源有限启动脚本里把这些配置写死能省掉后续大量debug时间。5.4 原则四给系统装一个“碎片水位计”碎片化是渐进过程最怕平时不监控、出事才手忙脚乱。我在生产环境里会用一段轻量脚本定时采集buddyinfo把max_order和order-8以上空闲块数作为指标推到监控系统。#!/bin/bash # frag_watch.sh while true; do max_order$(awk /Normal/ {for(i4;iNF;i) if($i0) maxi-4; print max0} /proc/buddyinfo) huge_free$(grep HugePages_Free /proc/meminfo | awk {print $2}) echo $(date %s) max_order$max_order huge_free$huge_free sleep 60 done阈值怎么定我一般以order-81MB为警戒线如果连续多次采样max_order低于8就发告警并准备重启进程或做内存整理的预案。很多问题在达到警戒线前其实有大量预警时间用脚本把“感觉”变成“数字”排查效率完全两样。5.5 硬件层面内存交织、Bank散列与映射的微调如果能接触到硬件配置还有几个锦上添花的点。多通道DDR的交织channel interleave会让连续物理地址轮流落到不同通道提高带宽具备地址散列address hashing的控制器能降低同一个bank的行冲突概率。碎片化已经让程序地址在物理上分散如果内存控制器再因为映射策略把所有访问都砸在同一个bank性能会更难看。实测同一块主板打开bank interleaving后跑内存带宽测试能高10%~25%不等。对硬件工程师来说另一个点是DDR颗粒的row/bank配置要和实际容量匹配并确保固件里启用了应有的纠错特性。这些配置好不好用lmbench的延迟测试和stream带宽测试跑一遍就能看出差异别靠猜。最后再多说一句我个人的习惯任何长期运行的C/C服务部署之后第一件事就是记录一份当时/proc/buddyinfo和/proc/meminfo的基线。之后每次版本发布、驱动升级后都做一次对比。碎片问题的特点就是它不会在你测试的十分钟里爆发而会在你上线三天后精准地咬你一口。提前把硬件视角纳入设计比事后加补丁省心太多。 
长河君 · 2026/9/10 18:28:13 · 阅读 1.2k 内存碎片问题从硬件视角排查：原理、定位与工程实践
上周一个朋友给我发来一段dmesg说他们的视频处理服务连续跑三天必出一次“page allocation failure”卡死前内存明明还剩30%。我让他把/proc/buddyinfo贴出来果然order-4以上全部为0。这已经不是第一次见这种问题了内存总量充足但硬件要的“连续”拿不出来。做内存管理优化如果只盯着虚拟内存、malloc/free永远差一层真正的裁判是硬件——MMU、TLB、DRAM bank、cache line、DMA控制器每一个都在用自己的规则检验你的内存布局。下面我就从硬件视角把排查内存碎片问题的完整思路整理一遍包括原理、实操命令和工程手段希望对写C/C服务、做嵌入式Linux、以及搞性能优化的朋友有用。1. 硬件眼中的地址虚拟地址、物理地址与页表如何参与碎片化1.1 你手里的指针是“座位号”不是“座位本身”很多做C/C的朋友有个惯性误区malloc返回一个地址就以为这块内存“已经有了”。在现代操作系统和带MMU的硬件上这个地址只是虚拟地址真正落到哪块物理内存是你在第一次写入或读取时由CPU触发缺页异常、内核分配物理页后才确定的。换成一个生活化的比喻虚拟地址是电影票上的座位号物理页才是影厅里那把真实的椅子。你拿着票进场票面印刷很漂亮但座位是不是连着的、周围坐没坐满陌生人得等检票那一刻才知道。这个模型决定了碎片问题的本质用户态看到的内存是“虚拟空间”里的连续地址物理内存是不是连续用户态根本感知不到直到某次需要大量物理连续内存的操作失败比如DMA映射、大页分配、巨型网络包处理你才会被现实扇一巴掌。更麻烦的是硬件视角下“连续”不是软概念CPU拿到一个虚拟地址要通过多级页表翻译成物理地址翻译失败就去缺页翻译成功后访问cachecache miss后交给内存控制器访问DRAM。整条链路里任何一环因为物理页过于分散而变慢都会直接体现在程序延迟上。1.2 地址粒度页(Page)是硬件认识的“最小单位”把物理内存切成固定大小的小块来管理是所有现代操作系统的基本玩法Linux默认4KB一页。为什么要按页切因为CPU的MMU只认这个粒度TLB缓存的是“虚拟页号→物理页号”的映射页表里每一项也对应一页。页的大小一旦固定物理连续性的要求就变成你要找的是一块由2的幂次个页组成的连续区域。这里要理解一个关键点虚拟地址连续不代表物理页连续。比如你malloc了1MB内核可能给你256个分散的4KB物理页。对普通CPU访问来说没问题因为MMU帮你翻译。但对于DMA、对于单次映射容量有限的硬件设备这是致命的。硬件层面看“碎片化”更精确的定义是物理内存中满足某种对齐和大小的连续空闲块数量不足。分配器要保证返回的起始地址按2的幂次对齐设备驱动经常要order-8甚至order-10的块。碎片越多这种块越稀罕。1.3 TLB碎片越多地址翻译越贵TLB是CPU内部容量很有限的缓存一般只有几十到几百个条目。它的作用是记住最近用过的虚拟页到物理页的映射避免每次访问都去内存查页表。TLB能覆盖的内存范围 条目数 × 页大小。假设CPU有64个L1 TLB条目用4KB小页只能覆盖256KB一旦你的工作集超过这个范围每访问几个新页面就会触发一次TLB MissCPU需要走到多级页表去逐级查。这就是碎片和硬件性能最直接的交汇点碎片妨碍了大页的使用。Linux的THP、HugeTLB需要2MB甚至1GB大小的物理连续页碎片严重时申请不到内核被迫退回4KB小页。同样的内存规模用4KB页需要的TLB条目数是用2MB大页的512倍。在我实测的一个Java服务场景里堆内存8GB启用THP前后TLB Miss从每千指令几十次降到个位数整机吞吐提升了约15%。别觉得15%不多在低延迟场景这可能就是超时率从千分之一涨到百分之三的差距。而碎片正是让THP失效的幕后推手。后来给一个Julia数值计算程序做性能优化时也遇到类似情况计算数组的存储布局一旦被打散TLB开销能直接让矩阵运算掉一半效率。2. DRAM内存控制器视角碎片化如何悄悄拖垮访问性能2.1 内存不是一块“大数组”是三维结构bank、row、column很多程序员把DRAM想象成一个大数组地址递增就是顺序读。真实情况是DDR颗粒内部划分成多个bank每个bank有一排row缓冲也叫行缓冲区。内存控制器访问一次数据得先激活目标rowACT命令然后在row缓冲里读写目标column如果下次访问落在同一个bank的另一个row就必须先把当前行写回Precharge再激活新行。这个“行冲突”的操作代价非常大。举一组典型参数DDR4-3200的tRCD大约13~15nstRAS约32nstRC约45ns。如果连续访问的地址恰好落在不同的row上每次都要处理行冲突延迟从几十ns飙升到百ns级别。反过来如果访问模式是顺序的同一个row里的连续burst基本都能命中行缓冲延迟低很多。碎片化的进程它的活跃内存页在物理上混乱散布内存控制器看到的就是一批又一批互不相邻的地址——这边的bank在activate那边的bank在precharge硬件预取器也失效带宽和延迟同时恶化。我在压力测试机上对比过同一程序内存布局顺序和打散后内存带宽下降20%~50%很常见。2.2 Cache Line层面的“邻居互害”伪共享和预取失效再往下到CPU缓存粒度。Cache Line通常是64字节物理相邻地址会被加载到同一个cache line。碎片化分配可能导致两个线程各自频繁写的变量被分到了同一个cache line里。两个核心同时写这个lineMESI协议会让这个line在两个核之间来回失效、重写这就是伪共享。一次伪共享触发可能出现几十到几百个时钟周期的开销而且完全隐藏在你的业务代码逻辑之外是最难查的那类性能问题。另一个容易被忽略的点是硬件预取器。现代CPU会观察顺序访问模式提前把后面128B、256B的内容拉进cache。前提是你访问的物理地址确实是连续或按固定步长递增。碎片化的物理布局会让逻辑上连续的buffer实际上东一块西一块预取器几乎每次都在猜错预取进来的数据很多用不上cache的有效命中率也会被稀释。2.3 DMA与硬件加速器场景物理连续是“刚需”而非“优化项”如果说CPU还能靠MMU帮你掩盖碎片问题那DMA就是压垮骆驼的最后一根稻草。网卡、NVMe控制器、USB控制器、GPU、DSP在做数据传输时走的是物理地址。如果平台没有IOMMU/SMMU做地址翻译驱动就必须拿到物理连续的缓冲区。碎片严重时驱动申请高order页面失败设备就报DMA error、ring buffer分配失败甚至直接crash。在嵌入式Linux上做视频采集或音频处理的朋友大概率见过CMA: cma_alloc: failed这种日志。CMA是一块预留的连续内存池平时允许Movable页面占用需要时把页面迁走再分配连续块。但当系统里全是长时间不挪动的匿名页或不可移动页时CMA分配照样失败。我自己维护的一个采集模块最初用kmalloc分配大块跑两三天后稳定复现DMA失败改成从CMA池分配并配合mlock固定关键页面后问题消除了。这里想强调的是硬件不关心你软件里有多少剩余内存它只认“给不给我一段连续物理地址”。3. 从Linux分配器看硬件妥协Buddy、SLAB、大页和CMA的真实取舍3.1 Buddy系统按2的幂切蛋糕外碎片的根源Linux物理内存分配的核心是Buddy System。它把空闲页按2的幂次分成不同order的块低order的块可以由相邻伙伴合并成高order高order块也能拆成低order用。这本来是为平衡分配效率与碎片率设计的但有一个先天问题外碎片。当内存中散布着大量不可移动的小块时低order块永远合并不成高order块虽然总量充足但order-8、order-10这种大片区域就是凑不出来。查看/proc/buddyinfo可以一眼看出系统碎片程度Node 0, zone Normal, 235 452 1080 3 0 0 0 0 0 0 0这一行从order-0到order-10分别是当前zone里每个order的空闲块数。上面例子里order-0有235块order-3有3块再往上全空说明系统能分配的最大连续块只有order-316个页即64KB。如果设备驱动要order-81MB当场失败但free命令看内存可能还剩好几GB。这就是碎片最典型的“总量与连续性背离”。3.2 SLAB/SLUB内碎片的温床物理页分配给内核后还需要细分成小对象供数据结构使用这是SLAB家族的活。kmalloc-64、kmalloc-192这类size class会从连续页里切成固定尺寸的小对象。问题是一个4KB页如果切成64字节对象理论上放64个但可能有对齐、元数据等损耗最后一小部分空间就废掉了。这属于内碎片分配出去的块内部浪费和外碎片空闲块太碎同属于碎片问题只是藏得更隐蔽。查看/proc/slabinfo能发现系统跑久了之后可能有成百上千个半满的kmalloc slab占用的物理页不少但实际对象利用率很低。很多嵌入式系统跑着跑着发现内存不够追查后发现内核slab占了2GB其中不少是碎片化的slab页。这种情况通常要配合slabinfo和trace定位是哪个内核路径在频繁创建不同size的临时对象。3.3 大页、THP、CMA用硬件特性反制碎片既然碎片让大页难申请Linux给了几个备选方案。HugeTLB是预分配式系统启动时或运行时预留一批2MB/1GB的大页专门给对性能和连续内存敏感的应用。思路是“早申请早安心”把物理连续性问题前置到系统启动阶段避开业务运行后的碎片化。THP则是自动的内核的khugepaged线程在后台扫描尝试把进程里的4KB页合并成2MB大页。如果碎片不严重这个合并能显著降低TLB压力但如果系统已经碎片化合并过程会触发内存规整compaction把大量页面搬来搬去造成CPU尖峰和延迟毛刺。我遇到过一台机器THP开启后业务高峰期每分钟触发一次长达几百毫秒的卡顿就是compaction在搬家。CMA则是DMA场景的保底系统启动时预留一段连续内存平时这段内存可以被Movable页面用于普通分配当驱动需要连续块时内核会把页面迁移走。它把“连续性成本”从静态浪费变成了动态迁移对嵌入式多任务场景很有用。4. 实测定位碎片从page allocation failure到buddyinfo的完整链路4.1 第一现场dmesg里的page allocation failure当内核无法满足某个order的分配时会打印一条page allocation failure日志包含关键信息请求order、gfp_mask、调用栈、当前zone的空闲页统计等。例如myapp: page allocation failure: order:4, mode:0xcc0(GFP_KERNEL) CPU: 2 PID: 1234 Comm: myapp Call Trace: __alloc_pages_nodemask0x... alloc_pages_vma0x... ... Normal: 118*4kB 56*8kB 3*16kB 0*32kB 0*64kB 0*128kB ...从这段日志里我第一眼会看order第二眼看队尾的连续块统计。order-4表示需要16个连续页64KB。日志显示32kB及以上为空说明失败原因不是“没内存”而是“没有连续64KB”。接下来顺着调用栈去查代码路径如果这个分配发生在网卡驱动里基本可以断定是碎片导致DMA buffer申请失败。4.2 /proc/buddyinfo三秒钟看懂碎片水位/proc/buddyinfo是排查碎片的温度计。我习惯用一段简短命令把每行的最大连续order算出来awk /Normal/ {for(i4;iNF;i){ if($i0) maxi-4 }; print max_ordermax} /proc/buddyinfo如果max_order长期低于664KB就属于高危状态低于4基本可以预告近期会出DMA或大页分配问题。建议在服务启动时记录一份baseline之后按小时对比观察碎片趋势。别等到线上故障才开始看那时候日志可能已经覆盖掉了。4.3 是谁在“挡路”page migrate type与长期存活页面Buddy系统把空闲页按迁移类型分成Unmovable、Reclaimable、Movable。Unmovable页不可迁移通常是内核分配、驱动分配Reclaimable页可以回收主要是page cacheMovable页可以迁移主要是用户态匿名页。在高碎片状态下频繁出现order分配失败时/proc/pagetypeinfo能告诉你哪些类型占据了空位、谁是主要阻挡者。更进一步的定位手段是ftrace的mm_page_alloc事件。在长期运行的进程里短暂开启trace就能通过调用栈确认是哪些代码路径不断申请不可移动的高order页。我见过一个case某个驱动每次IO都临时申请order-3用完也不释放时间一长Unmovable块碎成一片把所有order-6以上都卡死了。这种路径用代码评审很难发现必须靠trace数据说话。4.4 一次真实事故复盘视频服务连续运行三天的分配失败拿我去年处理过的一个case举例。一台视频转码服务器C实现跑三天必然出一次page allocation failure (order:4)然后采集线程异常退出。现场数据如下/proc/buddyinfo显示Normal zone order-4及以上全部为0/proc/pagetypeinfo显示Unmovable块在order-0到order-3占据了大量页面用ftrace追踪mm_page_alloc发现大量order-3级别的Unmovable分配来自某个USB摄像头驱动进一步检查驱动源码它在每次打开视频流时用kmalloc申请了128KB的中转buffer并且没有在关闭时释放干净泄漏加碎片共同作用。修复方案分两步驱动改成从固定CMA区域申请buffer并在模块加载时一次性分配、退出时释放应用侧把频繁创建销毁的转码缓冲改成对象池。上线后连续跑了两周buddyinfo稳定dmesg里再没出现过一次分配失败。这个case给我印象最深的是问题表象在内存分配器根因却横跨驱动、业务代码和硬件约束三层缺一层的排查都不完整。5. 工程对抗碎片分配策略、对象池与硬件特性配合的实用方案5.1 原则一把“长命对象”和“短命对象”隔离开碎片化的核心引擎是“长命对象与短命对象交错分配”。长命对象一旦分配往往不可迁移短命对象不断释放会在长命对象之间留下缺口。最优策略是一切长期存活、生命周期和进程一样长的对象在启动阶段就一次性分配好业务运行期尽可能不申请新的常驻大对象。这样留给运行时分配器的地址空间就是“干净”的连续区。对应到代码层就是初始化时把全局缓存、连接池、线程栈、共享内存都建好运行期用内存池来满足小的临时对象。这个原则在嵌入式Linux、C服务、游戏服务端都适用。很多人觉得看pmap虚拟内存量挺正常但物理内存分布平时看不出来真等碎片恶化到影响硬件分配代价就很重了。5.2 原则二用对象池替代频繁malloc/free对象池的思想简单粗暴把同一size class的对象预先分配一批维护一个空闲链表需要时从链表头部拿释放时挂回去。关键点是“绝不还给系统”避免频繁触发内核的页分配和释放。一个按size class分桶的对象池即使不做复杂的内存排序也能拦住90%以上业务代码产生的碎片。写Qt程序的时候尤其注意很多人习惯new一大堆QObject表面是C内存管理问题实际每次new都走一遍malloc对底层碎片的影响通常被忽略。这里有个容易踩的坑对象池里的对象如果跨越多个物理页使用后没有清零下一个使用者假设它是零初始化会读到脏数据。所以池化对象一定要在出池时做强契约要么你有字段标记版本号要么在分配时显式memset。此外池本身也要监控水位长期运行的进程如果池不断增长说明有泄漏别让池变成一个新的泄漏源。5.3 原则三对连续性敏感的资源主动预留如果你的系统里有硬件设备需要连续内存最好在启动阶段就预留到位。几条常用手段echo 64 /proc/sys/vm/nr_hugepages或者用hugetlb的cgroup接口给2MB大页留量设备树里预留reserved-memory/CMA区域确保驱动启动时能拿到连续块对用户态关键buffer调用mlock或mlockall防止被换出同时配合madvise(MADV_HUGEPAGE)引导内核给它们分配大页。预留的本质是“提前锁定物理资源”牺牲一部分弹性换硬件功能的稳定性。在一致性要求很高的产品里这是很划算的交易尤其是嵌入式硬件资源有限启动脚本里把这些配置写死能省掉后续大量debug时间。5.4 原则四给系统装一个“碎片水位计”碎片化是渐进过程最怕平时不监控、出事才手忙脚乱。我在生产环境里会用一段轻量脚本定时采集buddyinfo把max_order和order-8以上空闲块数作为指标推到监控系统。#!/bin/bash # frag_watch.sh while true; do max_order$(awk /Normal/ {for(i4;iNF;i) if($i0) maxi-4; print max0} /proc/buddyinfo) huge_free$(grep HugePages_Free /proc/meminfo | awk {print $2}) echo $(date %s) max_order$max_order huge_free$huge_free sleep 60 done阈值怎么定我一般以order-81MB为警戒线如果连续多次采样max_order低于8就发告警并准备重启进程或做内存整理的预案。很多问题在达到警戒线前其实有大量预警时间用脚本把“感觉”变成“数字”排查效率完全两样。5.5 硬件层面内存交织、Bank散列与映射的微调如果能接触到硬件配置还有几个锦上添花的点。多通道DDR的交织channel interleave会让连续物理地址轮流落到不同通道提高带宽具备地址散列address hashing的控制器能降低同一个bank的行冲突概率。碎片化已经让程序地址在物理上分散如果内存控制器再因为映射策略把所有访问都砸在同一个bank性能会更难看。实测同一块主板打开bank interleaving后跑内存带宽测试能高10%~25%不等。对硬件工程师来说另一个点是DDR颗粒的row/bank配置要和实际容量匹配并确保固件里启用了应有的纠错特性。这些配置好不好用lmbench的延迟测试和stream带宽测试跑一遍就能看出差异别靠猜。最后再多说一句我个人的习惯任何长期运行的C/C服务部署之后第一件事就是记录一份当时/proc/buddyinfo和/proc/meminfo的基线。之后每次版本发布、驱动升级后都做一次对比。碎片问题的特点就是它不会在你测试的十分钟里爆发而会在你上线三天后精准地咬你一口。提前把硬件视角纳入设计比事后加补丁省心太多。