虚拟存储与分页机制：从地址翻译到线上内存问题排查

刚带完的一批新人里几乎每个人看到“第五章 虚存技术”这个标题时第一反应都是“又臭又长的一章”。但等他们真正用调优工具排查过线上内存问题、被莫名其妙的卡顿折磨过之后都会回头承认一个事实——虚拟存储是整个操作系统里和日常开发、运维关联最紧密的机制之一没有“之一”。这篇内容我打算完全站在实操视角把虚拟存储的核心链条拆开它解决什么问题、分页和地址翻译怎么工作、缺页中断和置换算法怎么配合、以及你真正排查线上问题时会用到哪些底层规律。如果你正在学操作系统、准备面试或者因为线上应用内存表现诡异而头疼这篇应该能省下不少自己啃源码和文档的时间。先说个最容易被忽略的认知虚拟存储并不是一个“可有可无的加速选项”而是一个必需品。现代操作系统里进程拿到的地址从来就不是真实的物理内存地址而是一套独立编址的虚拟地址。每个进程都活在自己的“虚拟公寓”里以为自己拥有完整连续的内存空间实际上物理内存被操作系统当成了一块公共仓库谁真正要用了才临时把货搬进去。这套“假装拥有、按需分配、随时置换”的机制就是虚存技术。1. 虚存技术到底在解决什么问题1.1 物理内存不够用时的“拆东墙补西墙”在没有虚存机制的早期系统里程序能用的内存上限直接等于物理内存减去操作系统占用的部分。你写一个程序如果数据量超过了物理内存容量等待你的只有“内存不足”然后进程崩溃。这种模式对单个程序来说已经够难受更麻烦的是多任务场景——多个程序同时跑总内存需求轻而易举超过物理内存总量。虚拟存储的核心贡献在于引入了“换出”这个概念。内存里暂时不用的数据被换到磁盘上的交换区swap需要时再换回来。这就好比办公室工位不够用了行政把不常来的人安排到远程办公但每个人的工位牌上都还写着名字谁来上班就给他安排一个实际座位。对进程而言它的“工位牌”上始终写着同样连续的地址空间它根本不关心自己的数据此刻是被放在物理内存里还是躺在磁盘上。这一步的代价是磁盘IO换来的。内存访问是纳秒级别磁盘随机读写是毫秒级别差了五个数量级左右。所以虚存的成败本质上不在于“能不能换”而在于“怎么让换的动作尽量少发生换的时候尽量高效”。整章的页表结构、置换算法、工作集模型全都是围绕这两个目标展开的。1.2 内存隔离和“每个进程都有完整地址空间”的幻觉虚拟存储第二个容易被低估的作用是进程隔离。如果没有虚拟地址这层中间转换层任何进程都可以直接用内存地址访问物理内存那用户程序就能随便读写操作系统的内核数据也能把其他进程的数据改得乱七八糟。那不是一个可以接受的安全模型。有了虚拟存储之后每个进程的虚拟地址空间从0开始编址到某个上限结束看起来完整连续。用户态程序只能访问自己虚拟地址空间里标记为“用户态可访问”的页面内核区域即便出现在虚拟地址高位用户态也无法访问。更细的页表项里还带着读、写、执行权限位数据页即使被映射了默认也不能执行代码——这为后续的NX比特位保护和各类漏洞利用缓解机制提供了基础。这种“每家都以为自己住独栋别墅实际上住的是隔断间”的设计还带来一个开发体验上的巨大改善程序里固定的地址、栈的结构、代码段的布局不需要考虑物理内存被其他进程占了多少。链接器和加载器只需要为每个进程生成一套统一的地址布局剩下的事情全部由虚拟地址翻译机制兜底。1.3 懒分配和内存映射带来的额外红利虚存机制一旦建立起来系统设计者马上发现可以顺手做很多事。“按需分配”就是第一个红利进程申请大块内存时系统并不真的立刻找物理页而是只为你建立虚拟地址区域的映射真正访问到每一个页面时才分配物理页。这样进程哪怕申请了比物理内存还大的虚拟空间只要实际使用的部分很小照样可以跑起来。“内存映射文件”则是更深刻的应用。传统上读文件要经过“磁盘读入内核缓冲区再拷贝到用户缓冲区”两条路而有了页表翻译之后可以直接把文件内容映射到进程虚拟地址空间访问文件就像访问内存一样。首次访问触发缺页中断去读文件之后文件数据就以物理页的形式直接留在内存里。JVM加载jar包、可执行文件的装载底层都是这一套。理解这种“先画饼、后兑现”的机制之后很多问题都会有新的审视角度。比如为什么一个入了32GB内存的程序在系统监控里看到的驻留内存RSS才一点点又比如为什么内存一直没有真正用完但swap使用量却不断涨。这些现象全都要回到虚存机制最底层的“映射—按需填充—置换”模型里找答案。2. 分页机制与虚拟地址翻译的完整链路2.1 一切翻译都从页表项开始现代操作系统基本都以分页paging作为虚存实现的基础分段机制更多只扮演了逻辑辅助的角色。分页的思路很简单物理内存被切成固定大小的页帧通常4KBARM和x86处理器上还有2MB、1GB大页虚拟地址空间也被切成相同大小的页面。虚拟页号到物理页帧号的映射关系就存在每个进程独立的页表里。硬件CPU每次访问一个虚拟地址MMU内存管理单元就会拿虚拟地址的高位部分去查页表找到对应的页表项PTE然后从PTE里读出物理页帧号再和虚拟地址中的页内偏移拼起来形成最终的物理地址交给内存控制器去访问。你写的代码感觉自己是直接访问一块连续内存实际上每次访存都经历了这一趟翻译。页表项不仅仅记录物理页帧号还包含一组元信息常见的有存在位present页面此刻是否在物理内存里、读写权限位、用户/内核权限位、脏位页面被写过没有、访问位页面最近被访问过没有。存在位是0的那一瞬间就是缺页异常触发的时刻。脏位和访问位则是页面置换算法判断“该不该把某个页面写回磁盘”“哪个页面最近最少使用”的直接依据。我见过很多人把目录项结构背到滚瓜烂熟却不理解访问位、脏位为什么存在。实际写操作系统实验中这两个位相当好用——每次缺页之后都必须手动清访问位然后再次触发这样硬件就能用它们记录下来进程真实的访问模式。模拟时钟算法、判定工作集范围全都依赖这两个位。2.2 多级页表为什么能省这么多内存最直觉的页表设计是“一张大扁表”虚拟地址高位对应页表项索引一个页表项对应一个虚拟页。但算一笔账你就知道这个方案在64位系统上完全走不通。以48位虚拟地址、4KB页面为例这里省略了前缀位一级索引需要2的36次方个页表项每个页表项8字节单张页表占掉2的39次方字节512GB每启动一个进程都得给这么一张表根本不可能。多级页表的核心优化是“不给不存在的区域建表”。虚拟地址空间绝大多数区域是空洞进程真正用到的只是头部几段、栈区、堆区若干段。多级结构下高层的每一级目录项只覆盖一个大区间的映射如果这个区间进程从来没有映射过那这一项直接置空下面的子页表完全不需要分配。这样4级页表x86-64典型配置单进程页表总内存从不可行的512GB降到实际使用中通常几MB到几十MB的量级。这个“大区间按需分配”的思路不仅在页表里成立在文件系统里也成立稀疏文件、extent树在索引设计里也成立。理解多级页表本质上理解的是计算机系统里一个普遍规律可以用一两次额外指针跳转的代价交换大幅度的空间节省。2.3 TLB和局部性原理怎么让翻译不再成为瓶颈每次访存都去查四级页表等于每次内存读写前先额外做四五次内存读取性能损耗不可能接受。于是CPU在MMU内部加了一块非常小的缓存专门缓存最近使用的虚拟页号到物理页帧号的映射关系这就是TLBTranslation Lookaside Buffer。TLB的容量很小通常几十到几百条但它能撑起整个系统的性能靠的是程序的局部性。一个循环访问的数组虚拟页数有限这几百条TLB记录就足够覆盖热点区域。代码里写一个极端的随机访问程序每次跳到一个新页面TLB就会不停失效才会出现“访问同样的物理内存数量速度却天差地别”的现象。大页机制的本质也是从TLB下手把映射单位从4KB提升到2MB甚至1GB一个页表项能覆盖的范围大了512倍覆盖同样大小的内存区域需要的TLB条目大幅减少。数据库、大内存计算类应用在高负载下性能提升明显常常不是CPU算得快了而是TLB miss少了。3. 缺页中断与页面置换算法3.1 一次缺页中断背后有哪些环节当CPU访问一个映射存在但数据不在物理内存里的虚拟地址时MMU发现自己查到的PTE里存在位为0就会触发一个缺页异常操作系统接管处理。这个处理流程从宏观上看分三步找到空闲物理页把数据从磁盘换入这个物理页更新PTE并重新执行触发缺页的那条指令。如果说虚存是“假装有内存”缺页后系统就要“兑现承诺”。这个“兑现”过程里最值得注意的细节是凡是页面从磁盘读到内存全都走DMA直接到物理页不经过CPU手工逐字节拷贝而更新页表之后被中断的指令会从触发器位置重新执行而不是从下一条指令继续。这两个机制保证了缺页对用户进程的透明性——进程感知不到刚才发生过一次磁盘访问只是觉得自己执行变慢了。真正分析线上问题的时候需要关注的指标是缺页率单位时间里发生多少次缺页。缺页率太高说明程序的工作集大于分配的物理内存虚拟内存机制在全力以赴地把数据搬进搬出系统就会进入“页抖动”状态。这时候CPU使用率看着不高磁盘IO却很重整体响应时间表现出一种“假死”般的缓慢。3.2 页面置换算法从理想模型到实际可用的妥协在物理内存不够时缺页异常处理程序必须决定“要把哪个物理页页号换出去”。这个决策算法就是页面置换算法。学操作系统时最先接触的肯定是OPT最优置换理论上每次换走未来最久不再访问的页面缺页率最低。但OPT需要预知未来的访问序列实际不可实现它的价值在于作为一个评估基准——所有真实算法能达到的缺页率都以OPT为下限。FIFO是最直白的实现谁先进入内存谁先被换出。实现成本极低但有个致命问题叫Belady异常——在某些访问序列下给它的物理页数变多了缺页次数反而上升了。这违背直觉也让FIFO在正经系统里基本失去位置。LRU最近最久未使用是理论上的优等生替换最长时间没被访问的页面局部性强的负载表现很好。但真正的完全LRU需要为每次内存访问记录时间戳代价过高实际操作系统很少用纯LRU。常见替代方案是Clock算法时钟算法也叫二次机会算法用页表项的访问位循环扫描遇到访问位为1的页面先清位并跳过遇到为0的页面就选择它淘汰。这等价于一个近似的、用硬件访问位实现的LRU开销小很多效果足够好。很多教材还会讲NFU、老化算法、LFU等变体但在真实面试里能准确说出“为什么用Clock而不是纯LRU以及Clock和LRU在行为上的差异”就足够了。要记得一个点Clock没有全局的时间顺序它只能区分“最近被访问过”和“较久没被访问过”粒度比LRU粗。所以在高负载下会出现选择“命中频率较低但时间相对靠前”的页面被淘汰的情况。3.3 工作集模型与系统平滑性工作集就是进程在一段时间内实际访问的页面集合。如果系统分配给每个进程的物理页数小于它的工作集大小那么无论置换算法多聪明这个进程都会持续缺页。这不是置换策略的失败而是资源分配本身的失败。操作系统层面真正要做的是让所有进程的工作集总和不超过物理内存可用量并在这个前提下动态调整各进程的物理页配额。Linux内核后台有一个负责内存回收的线程通过计算每个进程的工作集、页面的年龄等信息在全局内存压力升高时主动回收页面而不是等到缺页中断时被动地临时找页。这也是为什么你会看到“程序不崩溃但系统的可用内存被内核不断压缩、交换”的情况。内核还提供了madvise、mlock等接口让应用显式告知自己哪些页更重要、不能被换出。善用这些接口往往比调整单个置换算法的参数更有效。4. 物理内存分配回收与多级页表实践4.1 伙伴系统让分配和回收都“规整”虚拟内存换页的过程底层需要一套高效的物理内存分配器。Linux内核用的是典型的伙伴系统把空闲页按2的幂次方组织成多个链表比如按1页、2页、4页、8页…一直到更大的块。要分配大小为n的物理页时内核从包含足够页数的最小链表里取块如果没有就向上取更大块然后把大块逐级拆小块把多余部分挂回对应链表。伙伴系统的精妙之处在于回收的时候如果发现两个相邻且大小相同的空闲块就立即合并成一个更大的块再递归向上合并。合并条件里的“相邻”特别关键正是这种“兄弟块合并”的规则保证了物理内存碎片不会无限积累。你可以把它理解成搭积木只用固定尺寸的乐高块相邻的两块如果都空着就拼成一块大的层层上拼。这样不管应用怎么反复申请释放最终总能拼出大块连续内存供DMA或大页分配使用。4.2 Slab/Slub缓存给内核对象发“免排队”通行证伙伴系统分配最小单位是物理页但内核里大量对象是几十字节到几百字节的结构体例如进程控制块、文件节点、socket缓冲区各部分的私有结构。如果每次都让伙伴系统按页分配光浪费在内部碎片上的内存就相当可观。Slab分配器新版内核里的实现叫SLUB的典型设计是为每种对象类型建立一个专属缓存先从伙伴系统拿一整页或多页内存然后切成同一大小的对象槽位内核要创建对象时直接从对应槽位里取对象销毁后这些槽位留着复用避免反复向伙伴系统申请和释放页面。常见的对象类型会长期维持一个稳定的缓存池比如网络连接对应的缓冲区、文件系统inode的描述信息等这也解释了为什么你观察系统内存时经常会看到若干MB甚至GB被标为“内核slab内存”——它并不是泄漏而是内核为高频分配对象准备的缓存。注意排查内存问题时看到Slab内存占用居高不下不要下意识删掉进程应该先查看具体是什么对象占了大头再决定是调整内核参数、避免某些子系统过度分配还是确实存在内核对象量过大的业务场景。4.3 地址翻译快慢路径和常见编码细节在操作系统实验或开发内核模块时会接触到二级或三级页表的源码实现这里有两个容易踩坑的编码细节值得单独说。第一页表项里的物理页号是高位对齐存放的天然空出低位来组合标志位如果你直接拿PTE里的值左移页内偏移位数去拼物理地址一定要先掩盖掉低位的权限标志。第二多级页表的下级页表起始地址同样要求按页大小对齐而PTE里某些高位会被保留用作NX等扩展标志位做地址拼装时不能保留这些位。把这些细节搞对往往才是实验里最容易花费时间的部分。很多同学调了半天崩溃或者读到错误数据最后发现只是没屏蔽标志位或者页面地址没有按对齐要求推进。建议动手实现分页功能时先给一个很小的物理地址空间跑通“页表项构造—访存—缺页—再填充”的完整流程再逐步扩大测试范围。5. 线上问题排查技巧与常见疑问5.1 怎么判断系统是不是在“页抖动”看到一个应用响应极慢首先怀疑内存不足时不要急着加机器。先看几个指标free命令里available内存是不是已经接近0vmstat输出的si、so两列是不是持续有非零数值。si和so分别代表swap换入换出的量如果这两列频繁出现数字说明系统页面换进换出的压力已经很大此时程序慢的根因大概率不是CPU而是磁盘IO在拖后腿。也可以看/proc/memory压力接口PSI输出的内存压力数值这个指标可以量化“因为等待内存回收、换页造成任务停顿的时间占比”。如果这个数值长期高于阈值那就是一个明确信号工作集超过物理内存了。此时该做的事情是分析应用是否真的需要这么大内存考虑优化数据结构、缓存淘汰策略而不是无脑扩容物理内存或者增加swap。5.2 进程实际占用的内存和虚拟地址空间为什么差这么多用ps或top看进程内存时常会看到两个数字VSZ虚拟内存大小和RSS驻留内存大小。VSZ可能高达几十GBRSS却只有几百MB新手往往会怀疑是不是看错了。这其实是虚存机制的正常表现进程申请了很大的地址空间或映射了很大的文件但并没有全部实际访问物理内存耗用当然只覆盖实际碰过的页面。RSS的增长也是离散的每访问一个新页面才多增加一个物理页。这个特征在排查内存泄漏时很有用。如果怀疑程序存在内存泄漏重点不应看VSZ的无脑上涨而应关注RSS持续增长趋势正常程序RSS会有一个温和的波动泄漏程序RSS往往只涨不跌。你还可以通过smaps接口查看进程内部细化到各虚拟内存区域的实际页数信息按映射区域判断到底是堆、栈还是某个文件映射产生的驻留内存占用。指标含义排查时怎么用VSZ虚拟地址空间总大小不代表实际内存占用跨进程对比意义不大RSS实际驻留物理内存观察增长趋势定位内存泄漏方向si/so换入/换出页速率持续非零说明内存压力大PSI /memory内存压力停顿指标高数值说明工作集超限major fault主缺页次数持续增长代表反复从磁盘加载页面5.3 关于Swap的取舍以及为什么盲目关掉不是好主意很多人遇到内存占用高、系统变慢时第一反应是关闭swap。这个做法在服务器场景下风险很大。Swap不是内存的备胎而是系统的“最后一道安全网”内存紧张时内核可以先把不活跃但需要保留的页面换出保留的物理内存留给真正活跃的数据。如果直接关掉swap内存一碰壁就直接触发OOM把进程中随机选一个干掉损失往往更大。合理的做法是保持一个不算太大的swap例如物理内存的25%~50%并通过vm.swappiness参数调整内核“倾向换出匿名页而不是缓存页”的程度。通常会把swappiness调低比如10到30之间让内核尽量少用swap但又不彻底禁用。线上是否完全不需要swap只适用于明确知道所有进程的工作集都远小于物理内存且保证不突变的场景这种判断需要建立在足够监控数据上而不该是默认的避险策略。5.4 一道常见的周期性问题可用内存明明很多为什么还在用swap这其实是一个虚假警报。Linux的“可用内存”包含文件缓存页面文件缓存是随时可以被回收的而swap的使用来源并不是因为物理内存总量不够而是某些匿名页面已经很长时间没有被访问过内核通过平衡机制顺手把它们换出了。只要可用内存足够、swap增长速度不快、si/si没有持续阻塞这种状态是正常的。遇到这种情况要改的不是关闭swap而是学会区分“自愿交换”内核主动把很久不用的页面挪出去换取空闲物理内存比例和“被迫交换”因物理内存持续不足而反复换入换出。自愿交换无害被迫交换危险。用vmstat的si/so列配合CPU使用率来看被迫交换通常会伴随waIO等待升高自愿交换则经常什么异常反应都没有。6. 一些让我印象深刻的实践经验第一点是关于模拟实验的。某次模拟实现虚存管理时最开始没有设置大页只用了最基础的4KB单级页表为了省事还在每次地址翻译时都重新遍历页表。结果跑一个稍大的测试程序速度比预期慢了几十倍。原因是页表项数量太多、TLB极小、每次遍历都产生内存访问。后来按书本方案上了多级页表和基本TLB模拟性能马上回到可接受范围。纸上谈兵觉得“工程优化只是加速”真正动手才知道虚存的效率完全建立在TLB和多级结构这些细节上。第二点是关于实战排障。有一次线上服务内存水位持续抬高各种常见排查手段都没有定位到明确问题后来发现问题出在一处mmap映射了超大文件但未使用madvise提示导致内核为它维护了大量页表项和元数据把这些映射细化到按区域来看才暴露出来。这类案例提示我们虚存技术不只是教科书上的概念它直接影响着手上的每一个大型应用的性能边界。搞懂第五章之后你再看内存监控工具输出的各种指标就会从“看数字”变成“看门道”。