Linux虚拟地址空间与物理内存管理：从页表到OOM排查实战

做Linux环境运维和C/C开发久了几乎每个人都会遇到一个绕不开的坎虚拟地址空间和物理内存。这两个词看着基础真到了排查内存泄漏、OOM、进程崩在诡异地址上的时候很多人还是会被绕晕。我最早也以为学会 free 和 top 就够了直到有一次线上进程莫名其妙被干掉才老老实实把虚拟内存这整套机制翻了个底朝天。这篇内容不聊教科书式的理论堆砌尽量用实际场景把进程地址空间、页表、伙伴系统、slab 这些概念串起来也把平时群里被反复问到的“磁盘满和内存满有什么区别”“rm 删除的文件能不能恢复”这类问题一起说清楚。适合刚开始接触 Linux 系统编程的同学也适合想补一补内存管理短板的开发和运维朋友。1. 虚拟地址空间为什么存在先把“隔离”和“翻译”想明白1.1 如果程序直接操作物理内存会怎样首先想一个问题如果没有虚拟地址空间程序直接读物理地址会怎样假设同时跑三个进程大家都往物理地址 0x1000 写数据结果必然互相踩踏一个进程里数组越界很可能直接改写另一个进程的数据更不要说恶意程序可以非常轻松地把整个物理内存翻一遍。没有虚拟内存每个进程还必须被加载到一块足够大的连续物理区域里物理内存早就碎成一片想找到一个能塞下大程序的连续空档都难换页、按需加载更无从谈起。所以虚拟地址空间存在的第一价值是隔离第二价值是让每个进程都以为自己拥有一整段连续、独立、从低到高排列的地址空间这是程序不必关心物理布局的基础。这里可以用生活场景打个比方物理内存像一家酒店的房间程序像客人。不能直接让客人拿着备用钥匙满楼跑而是给每家发一张房卡这张卡上写的是虚拟房号前台有一张表记录虚拟房号对应到哪个真实房间。这张表就是页表前台处理请求的过程叫地址翻译。历史上有过程序直接用物理地址的时期代价是系统只要跑两个程序就很容易出乱子而且硬件也不允许随意访问任意物理地址否则内核权限模型全线崩掉。正是这套“隔离翻译”的架构让现代操作系统能同时跑几百个进程而不互相干扰。1.2 一个进程的地址空间长什么样Linux 下每个进程都有独立地址空间内核用一个 mm_struct 描述它。经典的 x86 32 位布局里用户态占 0x00000000~0xBFFFFFFF3G内核态占 0xC0000000~0xFFFFFFFF1G64 位则大得多x86_64 目前常用 48 位地址用户态一般到 0x00007fffffffffff内核态地址则在 0xffff800000000000 以上。用户态空间从低地址到高地址大致是这样代码段、已初始化数据段、未初始化数据段、堆、mmap 映射区、栈、环境变量和参数区。堆向上增长栈向下增长中间的 mmap 区放动态库、共享内存和大型 malloc 分配这也是随机化ASLR保护的重点区域。想直观看到某个进程的完整布局最简单的方式是读 /proc/ /maps。我自己排查问题时几乎每次都先看这个文件cat /proc/1234/maps | head -20输出里每一行对应一个虚拟内存区域格式是“起始地址-结束地址 权限 偏移 设备 inode 路径”权限里的 r/x 决定了这块区域是否可读可执行。曾经有个客户说程序运行一段时间后“崩在了一个奇怪地址”我用 maps 一对比发现是栈被压到 mmap 区域里去了越界写把某个库的代码覆盖了。地址空间布局看着像一条直线实际上每一段都有严格边界越界本身不会被硬件立刻发现只有访问到没有映射的地址时才触发段错误。1.3 从虚拟地址到物理地址页表、TLB 与缺页异常地址翻译的核心是分页。Linux 默认 4K 一页一个地址就可以拆成“页号 页内偏移”。页号不能直接查一张大表现代 x86_64 用四级页表PML4 - PUD - PMD - PTE每一级存下一级的物理页帧号最后一级才指向真正的物理页。这个查找过程很像去大型仓库找货物先看哪个库房再找哪个货架再找哪一层最后定位到第几号储物格。指令执行时 CPU 的 MMU 自动完成翻译命中 TLB 就很快TLB 不命中就要多层查表开销大很多。这里有个非常容易踩的坑malloc 返回一个指针后你以为真的分到了物理内存其实没有。malloc 只是在进程地址空间里“挂了一个虚拟区域”第一次写入这个地址时才会触发缺页异常内核才真正分配物理页并填页表。这就是 Linux 按需调页demand paging的基本逻辑。曾经有同事分配 2GB 缓冲区程序基本只写前几十 MBfree 一看实际占用远没到 2GB他怀疑内存统计出错了其实就是这个机制在起作用。理解这一条对于看 free、top 时解释“VIRT 大不代表 RES 大”非常重要也是后面调 OOM 问题的前提。2. Linux 物理内存管理核心机制从页帧到 slab 再到 NUMA2.1 页帧与伙伴系统Linux 如何分配物理内存虚拟地址最终要映射到物理页。物理内存会被内核切分成大小统一的页帧page frame谁负责分配和回收这些页帧答案是伙伴系统buddy system。伙伴系统把空闲物理页按大小挂到不同链表里order 为 0 表示单页4Korder 为 1 表示 2 页连续8Korder 为 10 表示 1024 页连续4M。内核需要某一大小的连续内存时就从小到大找找不到就把更大的块一分为二一半返回给调用者另一半留在低 order 链表里回收时如果两半满足伙伴关系就合并成大块。这就是“外部碎片管理”的基本思路。看伙伴分布直接读 /proc/buddyinfo。这个文件平时用得少但在排查大页分配失败、DMA 缓冲区申请失败时特别有用cat /proc/buddyinfo从左到右是 order 0 到 order 10 的空闲页块数量。如果数字集中在低位 order表示内存已经碎得厉害想要 4M 的连续物理页很可能失败。曾经有个压测环境只要过一段时间业务就跑不动dmesg 里全是分配连续页失败free 完全正常顺着 buddyinfo 才发现是碎片化问题顺带把原因指向某个疯狂 malloc/free 的模块。所以别一听内存问题就怀疑泄漏碎片也是原因之一。2.2 slab/slub给内核对象“开小灶”伙伴系统按页管理但内核经常创建、销毁大量小对象比如进程的 task_struct、文件系统的 inode、dentry 缓存。如果每个对象都直接向伙伴系统申请一整页效率低得可怕。所以内核引入了 slab新版内核主要是 slub分配器先从伙伴系统拿一批页切成大小统一的对象之后对象分配和释放只在这个对象池里完成既减少了对伙伴系统的打扰也降低了对象初始化的重复成本。对频繁使用的结构体内核还会建立专用缓存比如用 kmem_cache_create 创建自己的对象池。观察 slab 占用有两个实用入口cat /proc/slabinfo 和 slabtop。如果你发现内存“不知道被谁吃掉了”top 里看不到用户进程占用但 free 显示 used 很高那十有八九是 slab 或 page cache。特别留意 SReclaimable 和 SUnreclaim 两个值前者可以回收后者回收不掉。我遇到过一例诡异现象系统跑几天后内存一直上涨用户进程全部杀掉后 used 依然很高最后用 slabtop 发现是某个文件系统驱动的 kmalloc-64 对象无限累积问题定位到驱动层面的对象未释放跟应用毫无关系。这类坑没有 slab 知识很难查。2.3 内存节点、区域与 NUMA物理内存还被分成不同 zone32 位下常见 ZONE_DMA、ZONE_NORMAL、ZONE_HIGHMEM64 位下主要用 ZONE_DMA、ZONE_DMA32 和 ZONE_NORMAL。DMA zone 用于外设直接访问的内存容量一般很小如果外设需要连续 DMA 缓冲order 比较大的分配就可能失败。机器上了 NUMA 之后内存按 CPU 节点分组每个 CPU 有本地内存和远端内存访问远端内存要走互联总线延迟更高。用 numactl --hardware 可以看到节点分布和拓扑。这里有个真实教训在 NUMA 机器上跑数据库实例节点0 内存已经分得差不多节点1 还有大量空闲但应用默认优先使用本地内存于是明明系统总内存充足某个进程却因为节点0 内存不足被 OOM。后来给配置加了 memory policy 或者 cgroup 均衡问题才消失。如果你用的是虚拟机也别忘了宿主机的 NUMA 拓扑会被透传或者隐藏盲目按物理机经验调参数很多时候会适得其反。2.4 观察内存的常用命令与要点先看 freefree -m关键是理解 total、used、free、buff/cache、available。其中 available 才是估出来的“还能用多少”因为它考虑了 page cache 可回收量。很多人看到 buff/cache 几GB就以为内存不够其实那是内核在做磁盘缓存应用程序有需要时会被收回。接下来是 vmstat 1 看 si/so、r、bsi/so 持续非 0 说明系统在反复换入换出物理内存真的不够用了。更进一步可以看 /proc/meminfo 的 MemTotal、MemFree、MemAvailable、CommitLimit、Committed_AS、Slab 等字段这是所有内存工具的数据源头信息比 free 全很多。ps 里的 VIRT、RES、SHR、DATA 经常被误解。VIRT 是进程的虚拟地址空间总大小包含代码、数据、栈、堆、共享库、mmap 等不等于真实占用RES 才是常驻物理内存SHR 是共享部分比如共享库和匿名共享页。一个程序 VIRT 显示 20GBRES 只有 1GB 是完全正常的可能只是预声明了大块虚拟地址但没有全部写入。想查更细读 /proc/ /smaps 或者 /proc/ /status里面 VmRSS、VmSize、RssAnon、RssFile 非常清楚适合判断到底哪些页在物理内存里。3. 实际场景从热词里挑几个高频内存问题做现场排查3.1 Linux 系统怎么看磁盘空间先分清内存和磁盘很多新手会把“内存不足”和“磁盘满”混在一起。它们都被叫作“空间”但是完全两种资源内存是字节存储掉电就没了磁盘是持久化存储。linux系统怎么看磁盘空间是搜索量很大的问题标准答法是 df 和 dudf -h df -i du -sh /var/log/*df -h 看文件系统使用率df -i 看 inodedu 看某目录实际占用。这里有个高频坑df 显示磁盘 100%但 du 统计下来所有文件加起来根本没那么多。原因通常是某个文件被 rm 删除后进程还持有文件描述符空间事实上没释放。用 lsof L1 就能列出这些“已删除但仍被占用”的文件。定位后重启对应进程或者 kill 掉磁盘空间就会回来。这类问题和内存清理经常被混在一起讨论但排查思路完全不同一个是看文件系统一个是看页表。3.2 物理内存分配为什么会失败OOM Killer 与 overcommitLinux 默认允许内存过量分配overcommit也就是说 malloc 时内核不一定真的检查物理内存是否够。vm.overcommit_memory0 是启发式malloc 很大一块可能照样成功真正的物理内存分配发生在写入时。这导致一种很常见的现象程序写内存写到一半内核发现物理内存不够了于是触发 OOM Killer挑一个进程杀掉。查杀进程记录命令dmesg -T | grep -i oom输出里会写着哪个进程被杀了当时内存占用多少以及 oom_score 排行。OOM 选择有打分机制oom_score 大致和进程占用物理内存正相关也会受到 oom_score_adj 影响。系统默认会倾向于杀内存占用最大的进程所以数据库类大内存进程特别容易中招。想保护某些关键服务可以调 oom_score_adj 或限制在 cgroup 里。但在调参之前一定先想清楚是不是虚拟机内存本身就被分配多了是不是写了太多 cache我个人踩过的坑是遇到 OOM 就着急关 swap、调 overcommit_memory2结果问题没解决反而把原本稳定的服务搞得更怪。合理做法是先看 dmesg、free、swap、cgroup再决定策略。3.3 rm -rf 删除的文件可以恢复吗一次关于页缓存和误删除的实战说明rm -rf 删除的文件可以恢复吗这也是热词。如果删除后立即有其它进程覆盖了数据块理论恢复希望极小但如果文件被删除时还有进程打开着数据就还在因为内核的文件引用计数没有变成 0。此时可以去 /proc/ /fd 里找到 fd直接复制出来ls -l /proc/1234/fd | grep deleted cp /proc/1234/fd/3 /path/to/rescue这样做的前提是被删文件对应的 inode 仍然被某个进程持有着。恢复出来的文件大小和内容一般完整之后立刻备份到其它磁盘。这也是为什么很多运维遇到误删后会先 lsof而不是马上重装系统或者重建分区因为操作越多恢复成功率越低。顺带说一句网上总有人问 Linux 系统分区能不能用 Ghost 备份这个说法有一定道理。Ghost 是基于扇区的镜像克隆方案它对文件系统内部结构理解得很浅而 Linux 分区里有 ext4 日志、UUID、引导信息直接用扇区块照搬回来后容易起不来。我不是说 Ghost 完全不能用而是备份 Linux 更推荐用 rsync、dd、LVM 快照、再生龙Clonezilla 类这类能感知文件系统的工具。这个话题和内存没有直接关系但很能说明“块级操作”和“文件级操作”的思维差异处理内存页和页表时也是同样道理千万别只盯着表象。3.4 长时间运行 sh 脚本没有日志输出怎么确认脚本正常“linux系统执行sh脚本长时间窗口无日志输出怎么查看脚本是否还在正常运行”又是一个高频问题。脚本没输出不等于没运行但也不等于内存没问题。一般步骤是先用 ps 找到脚本和子进程ps aux --forest | grep -E sh|your_script确认进程还在后读 /proc/ /status 里的 State 和 VmRSSState 是 R/S/D 中的哪一种D 通常表示不可中断睡眠比如卡在磁盘 I/O 或 NFS再配合 top 看 CPU 和 MEM 排序基本能判断是否在忙。如果怀疑是阻塞在某个系统调用可以 strace -p 看当前系统调用或者用 root 权限查 /proc/ /stack 看内核栈。我踩过的坑是脚本里有一段命令在等一个远端服务响应整个进程一直处于 S 状态没日志是因为标准输出被缓冲到内存里没落盘。后来习惯在脚本里加 stdbuf -oL 或者用 logger 直接写 syslog问题好查很多。从内存角度讲这里也值得留意如果脚本申请了大数组又没有释放VmRSS 持续涨最终也可能触发 OOM。所以脚本不输出时除了看进程状态也别忽略 VmRSS、VmSize、swap 的变化曲线。4. 常见问题与排查技巧实录4.1 free 里 buff/cache 占用高到底要不要清理不少人在看到 buff/cache 高后会急着 echo 3 /proc/sys/vm/drop_caches 去清。我的建议是绝大多数情况下不要。buff/cache 是内核用空闲内存做磁盘和文件缓存能显著加速读写不会长期挤占应用内存应用需要时内核会主动回收。真要在内存压力大时验证缓存是否可以回收可以先sync; echo 1 /proc/sys/vm/drop_cachesecho 1 只清 page cacheecho 2 清 dentry 和 inodeecho 3 两者都清。这是排障手段不是日常维护操作。特别对于跑数据库的机器清 cache 会拉高后续查询的 I/O反而让性能更差。我实测过在上千个文件的目录里做 git 操作清过 cache 之后速度立刻掉一截过一会儿热缓存回来才恢复。所以看到 cache 大先看 available数字够就说明缓存可回收不用管它。4.2 进程 RES 为什么降不下来内存瘦身的观察与取舍很多人发现某个进程的 RES 一直很高重启后立刻降过几天又涨。不一定就是泄漏常见原因有四个一是进程持续做 malloc/freeglibc 的 malloc 可能把释放过的一小块内存留在 arena 里形成碎片间隙被共享或 mmap 占用二是文件中被修改的脏页没有写回一直占物理内存三是共享库被多个进程映射RES 里包含共享部分四是 mmap 已经 unmap 但 TLB 相关缓存未刷新这个较少见。真正要看是不是泄漏可以连续记录 /proc/ /status 里的 VmRSS 和 VmSize看趋势。如果确认是持有太多不用的页可以调用 mallopt 或 malloc_trim(0)不过对 glibc 碎片的效果有限最稳妥的办法是重构分配策略或者定期重启进程。还有个小技巧用 madvise(MADV_DONTNEED) 主动释放一段明确不再使用的地址范围比重启进程要优雅。我在调试一个批量任务进程时就是靠这个函数把峰值 RSS 从 6GB 压到 3GB 以内的。不过这类优化要先分析哪个区域的内存分布占比高盲目 madvise 可能会误伤热数据。4.3 swap 使用与物理内存的关系以及虚拟机的“内存”误区swap 经常被误解成“虚拟内存”其实它是一个磁盘上的交换区用来在物理内存不够时把内存页换出来。判断系统是否真的在频繁交换重点看 vmstat 里的 si/so如果 si/so 长时间非 0说明物理内存已经紧张到内核在不停换页了。有的人一看到 swap 用了很多就赶紧 swapoff -a这非常危险因为 swapoff 必须把所有交换页读回物理内存如果内存不够系统可能直接 OOM。交换之前应该先确认 MemAvailable 足够大或者先加内存。虚拟机的场景也有类似误区。比如在宿主机上装 Linux 虚机看到虚机里 free 正常就以为宿主机内存够用实际上虚机的内存页全映射在宿主机的物理页上宿主机 OOM 时虚机体会异常卡顿甚至被杀。而 qcow2 是磁盘镜像文件不是内存镜像磁盘占用跟内存占用是两回事。换句话说虚机里“磁盘空间满”不代表“内存不够”宿主机“内存不够”很可能表现为虚机里的程序随机死掉。理解这一层才能正确诊断混合环境下的内存问题。4.4 快速记忆排查内存问题先看这四组数据我把自己习惯的排查顺序整理成了一张速查表遇到内存相关故障时按这个顺序来基本能覆盖八成问题数据源命令主要看什么内存总览free -hMemTotal、MemAvailable、buff/cache 是否正常内核统计cat /proc/meminfoSlab、CommitLimit、Committed_AS 是否逼近页分配cat /proc/buddyinfo连续大块页是否不足进程详情cat /proc/ /statusVmRSS、VmSize、State、RssAnon/RssFile这个表格不是万能的像 cgroup 内存限制、NUMA 策略、驱动泄漏等问题还需要额外工具但它能帮你快速确定大方向。记住一个原则物理内存分配失败、虚拟地址映射缺失、磁盘空间耗尽在这三者之间做区分是排障的第一步。很多人一上来就 top、free 乱试不如先花十秒确认问题到底发生在哪一层。最后再分享一点个人体会这几年来我实际处理过的内存问题里最后发现真相往往是“概念混淆”。把 page cache 当泄漏把虚拟地址空间大小当实际占用的物理内存把 swap 当虚拟内存把磁盘满当内存满。每次排查之前先问自己三句话我看的是虚拟内存还是物理内存谁在占用它这次故障是映射缺失、分配失败还是回收不及时把这三句话过一遍大多数问题已经能定位到七八分。想理解 Linux 的内存管理不需要买多少书直接把 free -m、vmstat 1 10、cat /proc/ /maps、cat /proc/buddyinfo 这些命令轮着看配合 dmesg 里的 OOM 日志来回对照几十次之后你对虚拟地址空间与物理内存的理解会远超面试标准因为那些工具不会骗人。