1. 从 free 命令里那两列数字的差距说起如果你在一台机器上敲过free -h大概率注意过这样一个现象free那一列只剩下几百兆看起来内存快见底了但available那一列还躺着好几个 G。第一次遇到这个差距的人往往会怀疑是不是显示错了实际上这两列数字的区别正好把内存管理这件事的核心矛盾摆在了台面上——操作系统关心的从来不是物理内存还剩多少字节而是已经被占用的内存里有多少是随时能拿回来的有多少是拿不回来的。这篇文章想聊的就是这条链路一个进程眼里连续、干净、独享的地址空间是怎么被内核一层层翻译成真实的物理页框的页面不够用的时候内核按什么规则挑人下手内核自己又怎么给自己分配物理内存。适合已经写过一些程序、知道指针和地址是什么但对为什么我的进程 RSS 一直在涨为什么 64G 的机器会 OOM这类问题只有一个模糊感觉的读者。我尽量不写教科书的定义而是按实际排查问题时会遇到的顺序来讲。1.1 虚拟内存到底替进程藏起了什么最朴素的理解是虚拟内存就是让每个进程以为自己独占一整块大内存。这个说法没错但太浅了它没解释清楚内核到底替进程摆平了哪些麻烦。我自己的理解是虚拟内存至少同时解决了四件互相纠缠的事而且这四件事是绑在一起解决的拆开任何一件都会出问题。第一件是隔离。进程 A 拿到地址 0x1000进程 B 也拿到 0x1000两者指向完全不同的物理页框。没有这层映射两个进程随便一个野指针就能改写对方的数据整个系统毫无稳定性可言。地址空间隔离是所有后续安全机制的地基包括权限位、只读页、不可执行页全都挂在页表项上。第二件是按需分配。程序启动时申请 1GB 内存内核并不会立刻找出 1GB 物理页给它只是把这段虚拟地址范围记在进程的 VMA 结构里标记为已承诺但未落地。真正分配发生在第一次访问那一刻由缺页中断触发。这就意味着一个申请了 1GB 但只用了 10MB 的进程实际只消耗 10MB 物理内存。这个特性直接支撑了超量承诺overcommit策略也是为什么free的available和used加起来对不上物理总量。第三件是共享。同一份动态库代码被一百个进程使用物理内存里只有一份一百个页表项都指向它。fork之后父子进程共享全部页面只有真正写入时才复制。这背后都是同一套机制页表项可以指向同一个物理页框。第四件是可以搬到磁盘上。物理页不够时久未访问的匿名页可以被换出到交换区页表项改成一个不在内存中的标记等下次访问再换回来。进程完全感知不到。提示这四件事里隔离和共享看着矛盾实际上是一体的——正因为每个进程有独立页表内核才敢让不同进程的页表项指向同一个物理页框。共享是显式协商出来的隔离是默认状态。1.2 一个进程的地址空间是怎么被切分的理解地址空间布局对排查问题特别有用因为很多内存涨了的现象先要看清楚涨的是哪一段。以常见的 64 位平台为例用户态地址空间大致切成这么几块代码段只读、可执行来自可执行文件的映射通常很小。数据段已初始化的全局变量和静态变量大小在编译期就基本确定。堆从低地址向高地址增长malloc在小块分配时走brk大块走mmap。共享库映射区从高地址向下增长mmap出来的匿名映射和大块分配也落在这里。栈主线程栈默认大小通常几 MB向低地址增长越界就是那个熟悉的段错误。内核态空间在用户态看不到但通过页表项的一个权限位和用户态严格隔开。这里有个细节值得记住堆和映射区是从两端往中间长的中间留出的空隙就是可用的虚拟地址预算。一个进程的虚拟地址空间理论上有上百 TB但真正能落地的物理内存受限于机器实际内存加交换区。我见过有同学写程序用malloc在一个循环里申请几百万个小块然后发现进程 VSZ 涨到了几十 GB 被系统限制住。原因不是物理内存不够而是每次malloc小块时堆区扩张虚拟地址一直在涨而释放后堆顶不一定能立刻回落。这类问题的排查思路后面会专门讲。2. 地址翻译链条上每一环都在消耗时间CPU 执行一条访存指令给出的地址是虚拟地址。这个地址要变成内存总线上真实发出的物理地址中间必须经过一次翻译。翻译本身需要读内存——因为页表就存在内存里——这就构成了一个自指的矛盾为了读一个字节先要读好几个字节。整个内存管理的性能设计本质上都是在解决这个矛盾。2.1 多级页表为了省内存付出的访问代价先说为什么不用单级页表。假设 48 位虚拟地址、4KB 页面、每页表项 8 字节那么页内偏移占 12 位剩下 36 位是页号一共 2^36 个页表项单级页表需要 2^36 × 8 512GB。每个进程一张这显然不可能。多级页表的思路是把这张巨大的表切成树。48 位地址拆成 9 9 9 9 12四级页表每级 512 项。每一级页表自己占 4KB正好一页。关键在于没有被使用的地址区间对应的下级页表根本不需要存在。一个进程实际用到的地址范围通常很稀疏四级结构下大部分中间节点都是空的实际消耗的页表内存可能只有几十 KB。代价是什么一次 TLB 未命中的地址翻译需要串行访问四级页表也就是四次内存读取最后一次才拿到物理页框号然后再访问一次目标数据总共五次内存访问。如果每级页表项都在缓存里可能几十个周期如果全部落空到主存那就是几百个周期。一条本来只要 4 个周期的load指令变成了几百个周期性能差了两个数量级。层级索引位宽作用缺失后果一级PGD9 位指向二级页表整段地址不可用二级PUD9 位指向三级页表大段地址不可用三级PMD9 位指向四级页表或直接映射大页中等粒度不可用四级PTE9 位指向物理页框单个 4KB 页不可用这张表里有个容易被忽略的点三级页表项可以直接指向一个 2MB 的大页跳过第四级。这就是大页机制在硬件层面的入口后面会再展开。2.2 TLB 的命中率决定了程序跑得虚不虚解决多级页表开销的办法是加缓存也就是 TLB。它是一块很小的、全相联或组相联的硬件缓存专门存虚拟页号到物理页框号的映射。命中时地址翻译几乎不花时间未命中才走完整的多级遍历。TLB 的容量小得可怜通常几十到几百项。按 4KB 页算覆盖范围也就几百 KB 到几 MB。这个数字直接决定了一个反直觉的结论程序的访存性能不只取决于缓存局部性还取决于页级局部性。如果你的程序在一个大数组上按步长 4096 字节跳跃访问每一两次访问就换一个页TLB 会被反复冲刷命中率掉到接近零即使数据全在 L3 缓存里性能也会塌下来。我做过一个对比实验遍历一个 512MB 的数组分别用连续访问、步长 64 字节、步长 4096 字节三种方式。连续访问和步长 64 字节的性能差不多步长 4096 那种直接慢了三四倍。原因就是每访问一次就跨一个页TLB 完全留不住映射。这个现象在矩阵转置、稀疏矩阵遍历、大哈希表探测里都特别常见。优化手段很朴素调整循环顺序让访问在页内聚集或者把大结构体按页对齐并减少跨页访问。提示/proc/interrupts里能看到 TLB 冲刷相关的计数某些架构上进程切换、页表修改都会触发冲刷。频繁的进程切换除了上下文开销还有一层 TLB 失效的隐性成本这是调度器设计时要权衡的因素之一。3. 缺页中断才是内存管理真正干活的地方前面说的都是已经映射好之后的事。真正让内存管理动起来的是缺页中断。进程访问一个虚拟地址硬件查页表发现这一项标记为无效于是触发异常控制流进入内核。内核在这一刻才决定这个地址该不该给它、从哪弄一页物理内存、要不要从磁盘读数据。3.1 一次缺页从发生到返回的完整路径处理逻辑大致按这个顺序走每一步都可能提前返回错误判断地址合法性。内核先看这个地址是否落在进程某个 VMA 范围内。如果压根不在任何 VMA 里那就是野指针直接给进程发段错误信号。这一步区分了程序有 bug和内存还没到位非常关键。检查访问权限。地址在 VMA 里但 VMA 标记为只读而这次是写操作同样是段错误。栈溢出踩到保护页也是走这条路。判断页类型。是文件映射页、匿名页、还是共享内存页类型不同后续处理分支完全不同。分配物理页框。从伙伴系统拿一页清零建立页表项设置权限位。填充数据。匿名页直接返回零页文件页需要发起磁盘读如果页缓存里已经有了就直接挂上写时复制的页需要复制一份新页。返回用户态重试。指令重新执行这次页表有效正常完成。这条路径里最容易出问题的是第 4 和第 5 步。分配物理页框时如果内存水位过低内核要先触发回收回收不动就可能直接触发 OOM 处理把某个进程杀掉。这种情况下你会看到一个进程莫名其妙消失而它自己毫无感知。磁盘读的情况更麻烦文件页缺页会阻塞在 IO 上如果底层存储慢进程就卡在那里表现出来就是程序偶发卡顿。3.2 匿名页、文件页、写时复制三种来源三套逻辑匿名页是没有后端文件支撑的内存堆、栈、malloc出来的大块都是它。它的内容只能靠交换区保存如果没有交换区这部分内存一旦被回收就直接丢失所以内核回收匿名页非常谨慎优先回收文件页。文件页背后有文件回收时如果页面干净直接丢掉即可下次访问再读如果页面脏了必须先写回磁盘才能丢。这就是为什么大量写文件会把内存吃满——脏页堆积内核必须等写回完成才能释放。很多内存居高不下的现象其实是页缓存占着属于可回收内存不该算作问题。写时复制是这两者之上的一个技巧。fork的时候内核不复制任何页只是把父子进程的所有页表项都改成只读并增加一个引用计数。任何一方尝试写入触发保护性缺页内核这时才复制一份新页给写的一方把它的页表项改成可写。这个设计让fork变得极快也让fork 之后立刻 exec这种最常见的用法几乎零成本。注意写时复制依赖引用计数如果实现有漏洞页可能被过早释放或者永远不释放。这类 bug 极难复现通常表现为某个进程内存缓慢泄漏或者某个页被意外改写。排查时盯住页表项和引用计数的一致性比盯住业务代码更有效。4. 内存不够用时内核怎么决定回收谁物理内存总有见底的时候。这时候内核必须做选择从哪个进程手里、拿回哪些页。这套选择机制直接决定了系统在压力下的表现是整体变慢但还能用还是突然卡死几秒然后某个进程被杀。4.1 双 LRU 链表与二次机会算法完全按访问时间排序的 LRU 理论最优但实现成本太高每次访问都要更新链表位置还要加锁多核环境下锁竞争会直接摧毁性能。所以实际用的是近似方案主流做法是维护两条链表——活跃链表和非活跃链表。页第一次被访问时挂在活跃链表头部。当需要回收时从非活跃链表尾部开始扫描检查页表项里的访问位如果访问位是 1说明最近被碰过把它移到活跃链表头部并清零访问位相当于给它第二次机会如果访问位是 0说明确实很久没用了直接回收。活跃链表太长时头部的页会被降级到非活跃链表形成一个循环。这个设计的好处是避免了每次访问都动链表的开销访问位的设置由硬件完成几乎零成本。代价是它只是个近似值某些访问模式下会退化。比如一个每秒访问一次但只访问一次的页访问位在扫描时刻恰好是 0就可能被误回收。这类场景要靠调整扫描策略或者使用更精细的机制来缓解。4.2 水位线、kswapd 与那只看不见的手回收不是等到内存彻底用完才开始而是分了几个水位线。每个内存区域有三个阈值高水位、低水位、最低水位。高于高水位内存充足回收线程休眠。低于低水位唤醒后台回收线程异步开始回收不影响正在跑的业务。低于最低水位所有分配内存的进程自己动手回收进入直接回收路径分配会阻塞。如果实在回收不出东西就触发 OOM。这个设计的关键在于异步回收和同步回收的分野。落在低水位区间时用户态几乎感觉不到一旦跌破最低水位所有申请内存的线程被迫自己去扫页表、写脏页、等 IO表现出来就是系统突然卡顿、响应变慢、吞吐暴跌。很多线上事故的现场就是这样内存没真正耗尽只是跌破水位的瞬间大量线程同时进入直接回收互相抢锁形成雪崩。水位状态触发动作用户可感知的影响高于高水位无无低水位与高水位之间后台回收线程逐步回收极轻微最低水位与低水位之间同步回收加异步回收并行部分请求延迟上升跌破最低水位分配线程直接回收明显卡顿可能触发杀进程调优的时候有个反直觉的经验适当调高最低水位让内核更早开始紧张反而能让系统更平稳。因为留出的缓冲更大异步回收有足够时间干活不容易跌进直接回收。当然调太高会浪费可用内存要看具体业务的内存增长曲线来定。5. 内核给自己分配内存的两级方案前面讲的都是面向用户进程的页管理。内核自己也要分配内存比如每个进程的任务结构、每个文件描述符、每个网络连接的状态这些东西大小不一、申请频繁用的是另一套机制。理解这套机制对看懂slab相关的内存统计很有帮助。5.1 伙伴系统连续页框的拆分与合并物理内存被切成一个个页框伙伴系统负责管理这些页框的分配。它的基本单位是阶2 的阶次方个连续页框为一组。阶为 0 是一个页阶为 10 是 1024 个连续页也就是 4MB。分配阶为 n 的内存块时如果对应链表空着就去 n1 阶找找到一块就劈成两半一半返回一半挂到 n 阶链表。如果 n1 也空继续往上找。释放时反过来如果相邻的伙伴块也空闲就合并成更高阶的块逐级往上递归。这个设计的核心价值是缓解外部碎片。假设你不断申请释放不同大小的块伙伴系统通过合并机制尽量让大的连续块能够重新拼出来。但它不能完全消除碎片如果一个 8 页的块里只有中间某一页被占用那这整个 8 页就再也拼不成一个完整的高阶块了。所以就引出了迁移类型的概念。内核把页框按可移动性分类不可移动的内核数据结构、可回收的页缓存、可移动的用户匿名页。分配时优先从同类区域拿避免把不同类型的页混在同一个大块里。这背后的逻辑很实在——如果可移动的页被隔离在一块区域里内核可以通过迁移整理出连续空间但如果中间夹着不可移动的内核结构那这块区域就永远碎片化了。5.2 slab 缓存小对象不该走大流程内核里大量对象只有几十到几百字节比如一个进程描述符大约几 KB一个 inode 几百字节。如果每个都走伙伴系统申请整页会浪费极其严重——一个 200 字节的对象占一整个 4KB 页内部碎片率 95%。而且这些对象创建销毁非常频繁每次都走一遍页分配和清零性能开销也扛不住。slab 的思路是搭在伙伴系统之上的一层缓存。针对每种常用对象建一个专用缓存缓存从伙伴系统批量拿页切成固定大小的槽位。申请对象时直接从缓存拿一个空闲槽位释放时归还槽位完全不动页框。这样既消除了内部碎片又让分配释放变成几个指针操作。清理策略通常分三种情况完全空闲的 slab 页可以还给伙伴系统部分使用的保留新对象优先从部分使用的 slab 分配让完全空闲的尽量攒出来。这个策略让高频小对象分配几乎不产生系统开销同时保持内存利用率。提示看内存统计时如果发现 slab 占用特别高先分清楚是正常缓存比如目录项、inode 缓存还是异常增长。正常的缓存会随内存压力自动收缩异常增长通常意味着某类对象泄漏。按缓存名字排序看增长速度比看总量有信息量得多。6. 线上排查内存问题先分清 VSZ、RSS、PSS讲完机制回到实际场景。内存相关的线上问题最常见的开场白是这个进程内存一直在涨。但在动手改代码之前得先搞清楚涨的是哪个数字不同数字背后的含义完全不同处理方向也完全相反。6.1 三个数字分别代表什么VSZ是虚拟地址空间大小包含了所有已映射但可能还没落地的地址范围。一个进程启动后 VSZ 动辄几个 G 很正常因为动态库映射、预留地址、线程栈都算在里面。VSZ 大不代表占内存只代表地址空间用得多。RSS是常驻集大小指当前真正映射在物理内存上的页数。但它有个陷阱共享页会被完整计入每一个共享它的进程。一百个进程共享一个 50MB 的库每个进程的 RSS 都多算 50MB加起来就是 5GB实际只用了 50MB。看 RSS 总和来判断机器内存压力会严重高估。PSS是按比例分摊后的数字共享页除以共享进程数。把所有进程的 PSS 加起来才接近真实占用。所以判断这台机器到底被谁吃了内存看 PSS 比看 RSS 靠谱得多。指标含义是否计入共享页适用场景VSZ虚拟地址空间总量计入判断地址空间是否异常膨胀RSS常驻物理内存完整计入单进程粗略观察PSS按比例分摊的常驻内存按份数分摊机器级内存归因USS进程独占内存不计入判断进程被杀能释放多少USS 是最少被提到但最有用的一个它是进程独占、不与任何其他进程共享的内存。当你要评估杀掉这个进程能腾出多少内存时USS 才是准确答案RSS 会高估PSS 会低估。6.2 一条从现象到根因的排查链路我一般按这个顺序走每一步都能砍掉一批可能性看机器层面。free里available是否真的紧张。如果available还很充裕只是某个进程 RSS 高那多半是页缓存或者共享库不需要处理。看回收情况。频繁的直接回收说明系统在内存压力下挣扎这时候问题可能不在某一个进程而是整体用量超过物理内存。按 PSS 排序找大户。锁定几个可疑进程分别看它们的增长曲线是阶梯式、线性还是脉冲式。阶梯式通常是缓存增长线性通常是泄漏脉冲式多半是批处理任务。看进程内部构成。是不是匿名页在涨是不是映射文件在涨映射文件涨通常无害匿名页涨才需要追。结合代码定位。到这一步才去看具体的分配点用采样或跟踪工具确认是哪条路径在持续申请。这条链路的价值在于它把内存涨了这个模糊现象分解成了几个互斥的假设每做一步就排除掉一批。直接跳到第 5 步去看代码很容易在无关的地方浪费几天时间。注意进程退出时内存不一定立刻归还系统。有些运行时环境会保留已释放的内存块用于后续复用所以看到内存不降不一定是泄漏。真正判断泄漏要看长时间运行下的趋势而不是单次操作前后的快照。7. 几个我在实际项目里反复踩到的坑机制讲完了最后分享几个具体的经验。这些大多不是文档里会强调的点但实际动手时踩上去的代价不小。7.1 mmap 完不等于占了物理内存我最早接触内存映射时有个错误认知mmap一大块内存进程就占了这么大。实际上mmap只是建立了虚拟地址到文件或匿名区域的映射关系物理页要等到第一次访问才分配。所以mmap一个 10GB 的文件进程 RSS 可能只有几 MB完全正常。这个特性有两个直接后果。好消息是它让你可以处理远大于物理内存的文件靠缺页按需加载。坏消息是如果访问模式很随机每次缺页都要读磁盘性能会惨不忍睹。我做过一个日志分析工具一开始用mmap直接映射整个文件再随机查跑起来比顺序读慢了十倍不止。后来改成按块顺序读加内存索引才恢复正常。还有一个坑是mmap之后的写入。匿名映射的页在被写之前指向一个全局零页只读。多个进程映射同一块匿名区域在写入前共享同一个零页写入时才各自分配。这意味着映射了 1GB 但只写了 1MB的情况下实际只占 1MB。反过来如果代码里对整块区域做了一次memset清零那就把 1GB 全部落地了RSS 立刻涨上去。7.2 大页不是越大越好大页的吸引力很明显一个 2MB 大页顶 512 个普通页页表项少了两个数量级TLB 覆盖范围扩大 512 倍缺页次数也大幅减少。对内存密集型的服务开大页经常能带来可观的性能提升。但它有几个隐性成本我吃过亏。第一是内存浪费。大页必须整块分配一个只用了 100KB 的 2MB 大页剩下 1.9MB 就浪费了。对于大量小对象的场景开了大页反而内存占用暴涨。第二是分配延迟。系统启动时如果预留了大量大页而没被使用这部分内存就锁死了其他进程用不了。第三是碎片问题。运行久了之后物理内存碎片化找不到连续的 2MB 块大页分配就会失败表现为有时候能开有时候开不了。我的经验是只有在确认 TLB 未命中是瓶颈之后再开大页而且要控制开启的范围。先用性能计数器确认 TLB 相关的开销占比确实高再在一个受控的服务上小范围试验对比内存占用和延迟两个指标两个都变好才推广。盲目全局开启很可能性能没提升多少内存先炸了。再补一个小技巧如果确实需要大页但内存紧张可以考虑按需折叠的思路让内核在检测到某个区域访问密集时才把相邻的普通页合并成大页而不是一开始就申请。这类机制在近年内核里逐步成熟但默认策略比较保守需要根据实际负载调参不建议在生产环境直接打开激进模式。最后说个排查时的小习惯。遇到内存相关的疑难问题我一般会先抓三份数据一份是内存水位和回收统计一份是进程级的 PSS 分布一份是内核内存分配器的分类统计。这三份数据放在一起看能快速判断问题出在用户态、页缓存还是内核结构上比一头扎进代码里高效得多。这个习惯帮我省下的时间比读任何一本讲内存管理的书都多。
1. 从 free 命令里那两列数字的差距说起如果你在一台机器上敲过free -h大概率注意过这样一个现象free那一列只剩下几百兆看起来内存快见底了但available那一列还躺着好几个 G。第一次遇到这个差距的人往往会怀疑是不是显示错了实际上这两列数字的区别正好把内存管理这件事的核心矛盾摆在了台面上——操作系统关心的从来不是物理内存还剩多少字节而是已经被占用的内存里有多少是随时能拿回来的有多少是拿不回来的。这篇文章想聊的就是这条链路一个进程眼里连续、干净、独享的地址空间是怎么被内核一层层翻译成真实的物理页框的页面不够用的时候内核按什么规则挑人下手内核自己又怎么给自己分配物理内存。适合已经写过一些程序、知道指针和地址是什么但对为什么我的进程 RSS 一直在涨为什么 64G 的机器会 OOM这类问题只有一个模糊感觉的读者。我尽量不写教科书的定义而是按实际排查问题时会遇到的顺序来讲。1.1 虚拟内存到底替进程藏起了什么最朴素的理解是虚拟内存就是让每个进程以为自己独占一整块大内存。这个说法没错但太浅了它没解释清楚内核到底替进程摆平了哪些麻烦。我自己的理解是虚拟内存至少同时解决了四件互相纠缠的事而且这四件事是绑在一起解决的拆开任何一件都会出问题。第一件是隔离。进程 A 拿到地址 0x1000进程 B 也拿到 0x1000两者指向完全不同的物理页框。没有这层映射两个进程随便一个野指针就能改写对方的数据整个系统毫无稳定性可言。地址空间隔离是所有后续安全机制的地基包括权限位、只读页、不可执行页全都挂在页表项上。第二件是按需分配。程序启动时申请 1GB 内存内核并不会立刻找出 1GB 物理页给它只是把这段虚拟地址范围记在进程的 VMA 结构里标记为已承诺但未落地。真正分配发生在第一次访问那一刻由缺页中断触发。这就意味着一个申请了 1GB 但只用了 10MB 的进程实际只消耗 10MB 物理内存。这个特性直接支撑了超量承诺overcommit策略也是为什么free的available和used加起来对不上物理总量。第三件是共享。同一份动态库代码被一百个进程使用物理内存里只有一份一百个页表项都指向它。fork之后父子进程共享全部页面只有真正写入时才复制。这背后都是同一套机制页表项可以指向同一个物理页框。第四件是可以搬到磁盘上。物理页不够时久未访问的匿名页可以被换出到交换区页表项改成一个不在内存中的标记等下次访问再换回来。进程完全感知不到。提示这四件事里隔离和共享看着矛盾实际上是一体的——正因为每个进程有独立页表内核才敢让不同进程的页表项指向同一个物理页框。共享是显式协商出来的隔离是默认状态。1.2 一个进程的地址空间是怎么被切分的理解地址空间布局对排查问题特别有用因为很多内存涨了的现象先要看清楚涨的是哪一段。以常见的 64 位平台为例用户态地址空间大致切成这么几块代码段只读、可执行来自可执行文件的映射通常很小。数据段已初始化的全局变量和静态变量大小在编译期就基本确定。堆从低地址向高地址增长malloc在小块分配时走brk大块走mmap。共享库映射区从高地址向下增长mmap出来的匿名映射和大块分配也落在这里。栈主线程栈默认大小通常几 MB向低地址增长越界就是那个熟悉的段错误。内核态空间在用户态看不到但通过页表项的一个权限位和用户态严格隔开。这里有个细节值得记住堆和映射区是从两端往中间长的中间留出的空隙就是可用的虚拟地址预算。一个进程的虚拟地址空间理论上有上百 TB但真正能落地的物理内存受限于机器实际内存加交换区。我见过有同学写程序用malloc在一个循环里申请几百万个小块然后发现进程 VSZ 涨到了几十 GB 被系统限制住。原因不是物理内存不够而是每次malloc小块时堆区扩张虚拟地址一直在涨而释放后堆顶不一定能立刻回落。这类问题的排查思路后面会专门讲。2. 地址翻译链条上每一环都在消耗时间CPU 执行一条访存指令给出的地址是虚拟地址。这个地址要变成内存总线上真实发出的物理地址中间必须经过一次翻译。翻译本身需要读内存——因为页表就存在内存里——这就构成了一个自指的矛盾为了读一个字节先要读好几个字节。整个内存管理的性能设计本质上都是在解决这个矛盾。2.1 多级页表为了省内存付出的访问代价先说为什么不用单级页表。假设 48 位虚拟地址、4KB 页面、每页表项 8 字节那么页内偏移占 12 位剩下 36 位是页号一共 2^36 个页表项单级页表需要 2^36 × 8 512GB。每个进程一张这显然不可能。多级页表的思路是把这张巨大的表切成树。48 位地址拆成 9 9 9 9 12四级页表每级 512 项。每一级页表自己占 4KB正好一页。关键在于没有被使用的地址区间对应的下级页表根本不需要存在。一个进程实际用到的地址范围通常很稀疏四级结构下大部分中间节点都是空的实际消耗的页表内存可能只有几十 KB。代价是什么一次 TLB 未命中的地址翻译需要串行访问四级页表也就是四次内存读取最后一次才拿到物理页框号然后再访问一次目标数据总共五次内存访问。如果每级页表项都在缓存里可能几十个周期如果全部落空到主存那就是几百个周期。一条本来只要 4 个周期的load指令变成了几百个周期性能差了两个数量级。层级索引位宽作用缺失后果一级PGD9 位指向二级页表整段地址不可用二级PUD9 位指向三级页表大段地址不可用三级PMD9 位指向四级页表或直接映射大页中等粒度不可用四级PTE9 位指向物理页框单个 4KB 页不可用这张表里有个容易被忽略的点三级页表项可以直接指向一个 2MB 的大页跳过第四级。这就是大页机制在硬件层面的入口后面会再展开。2.2 TLB 的命中率决定了程序跑得虚不虚解决多级页表开销的办法是加缓存也就是 TLB。它是一块很小的、全相联或组相联的硬件缓存专门存虚拟页号到物理页框号的映射。命中时地址翻译几乎不花时间未命中才走完整的多级遍历。TLB 的容量小得可怜通常几十到几百项。按 4KB 页算覆盖范围也就几百 KB 到几 MB。这个数字直接决定了一个反直觉的结论程序的访存性能不只取决于缓存局部性还取决于页级局部性。如果你的程序在一个大数组上按步长 4096 字节跳跃访问每一两次访问就换一个页TLB 会被反复冲刷命中率掉到接近零即使数据全在 L3 缓存里性能也会塌下来。我做过一个对比实验遍历一个 512MB 的数组分别用连续访问、步长 64 字节、步长 4096 字节三种方式。连续访问和步长 64 字节的性能差不多步长 4096 那种直接慢了三四倍。原因就是每访问一次就跨一个页TLB 完全留不住映射。这个现象在矩阵转置、稀疏矩阵遍历、大哈希表探测里都特别常见。优化手段很朴素调整循环顺序让访问在页内聚集或者把大结构体按页对齐并减少跨页访问。提示/proc/interrupts里能看到 TLB 冲刷相关的计数某些架构上进程切换、页表修改都会触发冲刷。频繁的进程切换除了上下文开销还有一层 TLB 失效的隐性成本这是调度器设计时要权衡的因素之一。3. 缺页中断才是内存管理真正干活的地方前面说的都是已经映射好之后的事。真正让内存管理动起来的是缺页中断。进程访问一个虚拟地址硬件查页表发现这一项标记为无效于是触发异常控制流进入内核。内核在这一刻才决定这个地址该不该给它、从哪弄一页物理内存、要不要从磁盘读数据。3.1 一次缺页从发生到返回的完整路径处理逻辑大致按这个顺序走每一步都可能提前返回错误判断地址合法性。内核先看这个地址是否落在进程某个 VMA 范围内。如果压根不在任何 VMA 里那就是野指针直接给进程发段错误信号。这一步区分了程序有 bug和内存还没到位非常关键。检查访问权限。地址在 VMA 里但 VMA 标记为只读而这次是写操作同样是段错误。栈溢出踩到保护页也是走这条路。判断页类型。是文件映射页、匿名页、还是共享内存页类型不同后续处理分支完全不同。分配物理页框。从伙伴系统拿一页清零建立页表项设置权限位。填充数据。匿名页直接返回零页文件页需要发起磁盘读如果页缓存里已经有了就直接挂上写时复制的页需要复制一份新页。返回用户态重试。指令重新执行这次页表有效正常完成。这条路径里最容易出问题的是第 4 和第 5 步。分配物理页框时如果内存水位过低内核要先触发回收回收不动就可能直接触发 OOM 处理把某个进程杀掉。这种情况下你会看到一个进程莫名其妙消失而它自己毫无感知。磁盘读的情况更麻烦文件页缺页会阻塞在 IO 上如果底层存储慢进程就卡在那里表现出来就是程序偶发卡顿。3.2 匿名页、文件页、写时复制三种来源三套逻辑匿名页是没有后端文件支撑的内存堆、栈、malloc出来的大块都是它。它的内容只能靠交换区保存如果没有交换区这部分内存一旦被回收就直接丢失所以内核回收匿名页非常谨慎优先回收文件页。文件页背后有文件回收时如果页面干净直接丢掉即可下次访问再读如果页面脏了必须先写回磁盘才能丢。这就是为什么大量写文件会把内存吃满——脏页堆积内核必须等写回完成才能释放。很多内存居高不下的现象其实是页缓存占着属于可回收内存不该算作问题。写时复制是这两者之上的一个技巧。fork的时候内核不复制任何页只是把父子进程的所有页表项都改成只读并增加一个引用计数。任何一方尝试写入触发保护性缺页内核这时才复制一份新页给写的一方把它的页表项改成可写。这个设计让fork变得极快也让fork 之后立刻 exec这种最常见的用法几乎零成本。注意写时复制依赖引用计数如果实现有漏洞页可能被过早释放或者永远不释放。这类 bug 极难复现通常表现为某个进程内存缓慢泄漏或者某个页被意外改写。排查时盯住页表项和引用计数的一致性比盯住业务代码更有效。4. 内存不够用时内核怎么决定回收谁物理内存总有见底的时候。这时候内核必须做选择从哪个进程手里、拿回哪些页。这套选择机制直接决定了系统在压力下的表现是整体变慢但还能用还是突然卡死几秒然后某个进程被杀。4.1 双 LRU 链表与二次机会算法完全按访问时间排序的 LRU 理论最优但实现成本太高每次访问都要更新链表位置还要加锁多核环境下锁竞争会直接摧毁性能。所以实际用的是近似方案主流做法是维护两条链表——活跃链表和非活跃链表。页第一次被访问时挂在活跃链表头部。当需要回收时从非活跃链表尾部开始扫描检查页表项里的访问位如果访问位是 1说明最近被碰过把它移到活跃链表头部并清零访问位相当于给它第二次机会如果访问位是 0说明确实很久没用了直接回收。活跃链表太长时头部的页会被降级到非活跃链表形成一个循环。这个设计的好处是避免了每次访问都动链表的开销访问位的设置由硬件完成几乎零成本。代价是它只是个近似值某些访问模式下会退化。比如一个每秒访问一次但只访问一次的页访问位在扫描时刻恰好是 0就可能被误回收。这类场景要靠调整扫描策略或者使用更精细的机制来缓解。4.2 水位线、kswapd 与那只看不见的手回收不是等到内存彻底用完才开始而是分了几个水位线。每个内存区域有三个阈值高水位、低水位、最低水位。高于高水位内存充足回收线程休眠。低于低水位唤醒后台回收线程异步开始回收不影响正在跑的业务。低于最低水位所有分配内存的进程自己动手回收进入直接回收路径分配会阻塞。如果实在回收不出东西就触发 OOM。这个设计的关键在于异步回收和同步回收的分野。落在低水位区间时用户态几乎感觉不到一旦跌破最低水位所有申请内存的线程被迫自己去扫页表、写脏页、等 IO表现出来就是系统突然卡顿、响应变慢、吞吐暴跌。很多线上事故的现场就是这样内存没真正耗尽只是跌破水位的瞬间大量线程同时进入直接回收互相抢锁形成雪崩。水位状态触发动作用户可感知的影响高于高水位无无低水位与高水位之间后台回收线程逐步回收极轻微最低水位与低水位之间同步回收加异步回收并行部分请求延迟上升跌破最低水位分配线程直接回收明显卡顿可能触发杀进程调优的时候有个反直觉的经验适当调高最低水位让内核更早开始紧张反而能让系统更平稳。因为留出的缓冲更大异步回收有足够时间干活不容易跌进直接回收。当然调太高会浪费可用内存要看具体业务的内存增长曲线来定。5. 内核给自己分配内存的两级方案前面讲的都是面向用户进程的页管理。内核自己也要分配内存比如每个进程的任务结构、每个文件描述符、每个网络连接的状态这些东西大小不一、申请频繁用的是另一套机制。理解这套机制对看懂slab相关的内存统计很有帮助。5.1 伙伴系统连续页框的拆分与合并物理内存被切成一个个页框伙伴系统负责管理这些页框的分配。它的基本单位是阶2 的阶次方个连续页框为一组。阶为 0 是一个页阶为 10 是 1024 个连续页也就是 4MB。分配阶为 n 的内存块时如果对应链表空着就去 n1 阶找找到一块就劈成两半一半返回一半挂到 n 阶链表。如果 n1 也空继续往上找。释放时反过来如果相邻的伙伴块也空闲就合并成更高阶的块逐级往上递归。这个设计的核心价值是缓解外部碎片。假设你不断申请释放不同大小的块伙伴系统通过合并机制尽量让大的连续块能够重新拼出来。但它不能完全消除碎片如果一个 8 页的块里只有中间某一页被占用那这整个 8 页就再也拼不成一个完整的高阶块了。所以就引出了迁移类型的概念。内核把页框按可移动性分类不可移动的内核数据结构、可回收的页缓存、可移动的用户匿名页。分配时优先从同类区域拿避免把不同类型的页混在同一个大块里。这背后的逻辑很实在——如果可移动的页被隔离在一块区域里内核可以通过迁移整理出连续空间但如果中间夹着不可移动的内核结构那这块区域就永远碎片化了。5.2 slab 缓存小对象不该走大流程内核里大量对象只有几十到几百字节比如一个进程描述符大约几 KB一个 inode 几百字节。如果每个都走伙伴系统申请整页会浪费极其严重——一个 200 字节的对象占一整个 4KB 页内部碎片率 95%。而且这些对象创建销毁非常频繁每次都走一遍页分配和清零性能开销也扛不住。slab 的思路是搭在伙伴系统之上的一层缓存。针对每种常用对象建一个专用缓存缓存从伙伴系统批量拿页切成固定大小的槽位。申请对象时直接从缓存拿一个空闲槽位释放时归还槽位完全不动页框。这样既消除了内部碎片又让分配释放变成几个指针操作。清理策略通常分三种情况完全空闲的 slab 页可以还给伙伴系统部分使用的保留新对象优先从部分使用的 slab 分配让完全空闲的尽量攒出来。这个策略让高频小对象分配几乎不产生系统开销同时保持内存利用率。提示看内存统计时如果发现 slab 占用特别高先分清楚是正常缓存比如目录项、inode 缓存还是异常增长。正常的缓存会随内存压力自动收缩异常增长通常意味着某类对象泄漏。按缓存名字排序看增长速度比看总量有信息量得多。6. 线上排查内存问题先分清 VSZ、RSS、PSS讲完机制回到实际场景。内存相关的线上问题最常见的开场白是这个进程内存一直在涨。但在动手改代码之前得先搞清楚涨的是哪个数字不同数字背后的含义完全不同处理方向也完全相反。6.1 三个数字分别代表什么VSZ是虚拟地址空间大小包含了所有已映射但可能还没落地的地址范围。一个进程启动后 VSZ 动辄几个 G 很正常因为动态库映射、预留地址、线程栈都算在里面。VSZ 大不代表占内存只代表地址空间用得多。RSS是常驻集大小指当前真正映射在物理内存上的页数。但它有个陷阱共享页会被完整计入每一个共享它的进程。一百个进程共享一个 50MB 的库每个进程的 RSS 都多算 50MB加起来就是 5GB实际只用了 50MB。看 RSS 总和来判断机器内存压力会严重高估。PSS是按比例分摊后的数字共享页除以共享进程数。把所有进程的 PSS 加起来才接近真实占用。所以判断这台机器到底被谁吃了内存看 PSS 比看 RSS 靠谱得多。指标含义是否计入共享页适用场景VSZ虚拟地址空间总量计入判断地址空间是否异常膨胀RSS常驻物理内存完整计入单进程粗略观察PSS按比例分摊的常驻内存按份数分摊机器级内存归因USS进程独占内存不计入判断进程被杀能释放多少USS 是最少被提到但最有用的一个它是进程独占、不与任何其他进程共享的内存。当你要评估杀掉这个进程能腾出多少内存时USS 才是准确答案RSS 会高估PSS 会低估。6.2 一条从现象到根因的排查链路我一般按这个顺序走每一步都能砍掉一批可能性看机器层面。free里available是否真的紧张。如果available还很充裕只是某个进程 RSS 高那多半是页缓存或者共享库不需要处理。看回收情况。频繁的直接回收说明系统在内存压力下挣扎这时候问题可能不在某一个进程而是整体用量超过物理内存。按 PSS 排序找大户。锁定几个可疑进程分别看它们的增长曲线是阶梯式、线性还是脉冲式。阶梯式通常是缓存增长线性通常是泄漏脉冲式多半是批处理任务。看进程内部构成。是不是匿名页在涨是不是映射文件在涨映射文件涨通常无害匿名页涨才需要追。结合代码定位。到这一步才去看具体的分配点用采样或跟踪工具确认是哪条路径在持续申请。这条链路的价值在于它把内存涨了这个模糊现象分解成了几个互斥的假设每做一步就排除掉一批。直接跳到第 5 步去看代码很容易在无关的地方浪费几天时间。注意进程退出时内存不一定立刻归还系统。有些运行时环境会保留已释放的内存块用于后续复用所以看到内存不降不一定是泄漏。真正判断泄漏要看长时间运行下的趋势而不是单次操作前后的快照。7. 几个我在实际项目里反复踩到的坑机制讲完了最后分享几个具体的经验。这些大多不是文档里会强调的点但实际动手时踩上去的代价不小。7.1 mmap 完不等于占了物理内存我最早接触内存映射时有个错误认知mmap一大块内存进程就占了这么大。实际上mmap只是建立了虚拟地址到文件或匿名区域的映射关系物理页要等到第一次访问才分配。所以mmap一个 10GB 的文件进程 RSS 可能只有几 MB完全正常。这个特性有两个直接后果。好消息是它让你可以处理远大于物理内存的文件靠缺页按需加载。坏消息是如果访问模式很随机每次缺页都要读磁盘性能会惨不忍睹。我做过一个日志分析工具一开始用mmap直接映射整个文件再随机查跑起来比顺序读慢了十倍不止。后来改成按块顺序读加内存索引才恢复正常。还有一个坑是mmap之后的写入。匿名映射的页在被写之前指向一个全局零页只读。多个进程映射同一块匿名区域在写入前共享同一个零页写入时才各自分配。这意味着映射了 1GB 但只写了 1MB的情况下实际只占 1MB。反过来如果代码里对整块区域做了一次memset清零那就把 1GB 全部落地了RSS 立刻涨上去。7.2 大页不是越大越好大页的吸引力很明显一个 2MB 大页顶 512 个普通页页表项少了两个数量级TLB 覆盖范围扩大 512 倍缺页次数也大幅减少。对内存密集型的服务开大页经常能带来可观的性能提升。但它有几个隐性成本我吃过亏。第一是内存浪费。大页必须整块分配一个只用了 100KB 的 2MB 大页剩下 1.9MB 就浪费了。对于大量小对象的场景开了大页反而内存占用暴涨。第二是分配延迟。系统启动时如果预留了大量大页而没被使用这部分内存就锁死了其他进程用不了。第三是碎片问题。运行久了之后物理内存碎片化找不到连续的 2MB 块大页分配就会失败表现为有时候能开有时候开不了。我的经验是只有在确认 TLB 未命中是瓶颈之后再开大页而且要控制开启的范围。先用性能计数器确认 TLB 相关的开销占比确实高再在一个受控的服务上小范围试验对比内存占用和延迟两个指标两个都变好才推广。盲目全局开启很可能性能没提升多少内存先炸了。再补一个小技巧如果确实需要大页但内存紧张可以考虑按需折叠的思路让内核在检测到某个区域访问密集时才把相邻的普通页合并成大页而不是一开始就申请。这类机制在近年内核里逐步成熟但默认策略比较保守需要根据实际负载调参不建议在生产环境直接打开激进模式。最后说个排查时的小习惯。遇到内存相关的疑难问题我一般会先抓三份数据一份是内存水位和回收统计一份是进程级的 PSS 分布一份是内核内存分配器的分类统计。这三份数据放在一起看能快速判断问题出在用户态、页缓存还是内核结构上比一头扎进代码里高效得多。这个习惯帮我省下的时间比读任何一本讲内存管理的书都多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
