前几天线上一个 Java 服务被内核 OOM killer 干掉了运维把截图甩过来free -h里明明还躺着 3 个 G 的 MemFree一堆人第一反应都是内存够啊凭什么杀我进程。这正是Linux 内存管理最反直觉的地方——你以为的空闲内存跟内核真正能立刻掏出来用的内存压根不是一回事。这篇就把 Linux 内存管理里最容易被讲糊的三个核心概念拆开揉碎虚拟内存、物理内存、进程地址空间。不管你是刚装完 Linux 系统、连free输出都看不明白的新手还是准备面试被追问缺页异常到底怎么走的工程师又或者是调服务器时被swappiness、overcommit这些参数绕得头晕的运维都能在下面找到能直接上手的东西。我不打算复述教科书里那套分页机制定义而是沿着内核为什么这么设计、实际跑起来长什么样、出问题拿什么查这条线把每个环节串起来讲。整篇内容偏实战命令都验证过参数都算过账踩过的坑也一并告诉你。1. 先想明白Linux 内存管理到底在管什么在展开细节之前得先把三层这件事立起来。很多人学内存管理学得痛苦根本原因是把三件事混着看物理内存是硬件插在主板上的那几根条子虚拟内存是内核对上层提供的一套地址抽象而进程地址空间是每个进程独享的那份内存地图。这三者层层嵌套物理内存被虚拟内存系统接管虚拟内存又按进程切成一块块地址空间。理解了这个嵌套关系后面所有概念就都有了挂靠点。1.1 为什么一定要有虚拟内存这层中间商假设没有虚拟内存每个进程直接操作物理地址那会立刻冒出三个要命的问题。第一进程之间没有任何隔离A 进程一个野指针就能把 B 进程的数据改掉系统根本谈不上安全。第二内存分配会变成找连续空位的游戏跑久了外部碎片能把 4G 内存碎得连一个 1M 连续块都拼不出来。第三程序编译时必须知道自己会加载到哪个物理地址可实际上每次运行位置都可能变链接器要疯。虚拟内存就是来解决这三个问题的。每个进程都拿到一张独立的虚拟地址空间从 0 一直到用户空间上限看起来整块内存都是我一个人的。进程只管用虚拟地址内核在背后偷偷把虚拟地址翻译成真实物理地址。这样隔离有了进程互相看不见对方的物理页碎片问题缓解了物理页不需要连续只要虚拟页连续就行位置无关也成立了程序永远从固定虚拟地址开始物理位置随便放。我第一次真正开窍是在纸上画了一遍地址翻译流程之后。你会发现虚拟内存这个词其实有两副面孔对应用程序来说它是我拥有的内存对内核来说它是一个需要维护页表来翻译的映射集合。把这两副面孔分清楚很多困惑自己就散了。1.2 三层抽象各自的职责边界物理内存这一层内核要解决的是怎么在大大小小的分配请求之间高效切分真实的 RAM。这里的关键词是伙伴系统、slab 分配器、内存水位。这一层对内普通应用基本碰不到但出问题时最先露馅。虚拟内存这一层内核要解决的是怎么把虚拟地址翻译成物理地址并且在物理页不够时还能撑住。关键词是页表、TLB、缺页异常、按需分页、页面回收、swap。这一层是承上启下的核心。进程地址空间这一层内核要解决的是怎么描述一个进程用了哪些虚拟地址区间、这些区间是什么属性。关键词是VMA、mmap、brk、写时复制。你写 C 程序调malloc、用mmap映射文件动到的就是这一层。三层之间是调用关系进程地址空间描述了要映射什么虚拟内存系统负责把映射建起来并翻译物理内存管理负责真正拿出页来放数据。理清这条链再去看/proc/meminfo、pmap、smaps里的数字就不会觉得它们是一堆无关紧要的计数器了。2. 物理内存内核手里那点真金白银怎么管物理内存是整栋楼的地基虽然应用层看不见但它的管理策略决定了整机在高负载下是稳如老狗还是频繁抖动。这一层最值得动手去看的就是内核把物理内存按什么粒度组织、用什么算法分配、什么时候开始紧张。下面从组织方式讲到实操查看。2.1 NUMA 节点、内存区和页帧的三级组织现代服务器几乎都是 NUMA 架构CPU 访问本地内存节点比访问远端节点快得多。所以内核第一件事就是按 NUMA 节点node把物理内存分组每个 node 内部再按用途划分成不同的 zone。x86_64 上常见的有ZONE_DMA给老式外设用的低地址区、ZONE_DMA32、ZONE_NORMAL普通可用内存、ZONE_MOVABLE可迁移内存用于内存热插拔和大页。zone 这一层存在的意义是不同硬件对地址范围有硬性要求比如某些 DMA 设备只能寻址 16M 以下。再往下zone 被切成一个个固定大小的页帧page frame标准大小 4KB。内核用struct page这个结构体描述每一个物理页帧的状态——是否空闲、被谁引用、是不是脏页。这个结构体本身就要占内存所以 4KB 页的管理开销是实打实存在的。理解管理元数据也要吃内存这一点后面看Slab、PageTables这些字段时就不会惊讶了。组织层次可以简单记成node → zone → page frame。知道这个层级最直接的好处是当你看到numactl --hardware输出多个 node而某个进程只跑在一个 node 上时能立刻意识到可能出现跨 node 访问或内存分配不均的问题。2.2 伙伴系统与 slab两种粒度两种打法内核分配物理页的主力是伙伴系统buddy system。它把空闲页按 2 的幂次分成不同大小的块从 2^0 个页一直到 2^(MAX_ORDER-1) 个页常见 MAX_ORDER 为 11也就是最大 2^10 1024 页约 4MB。分配 4KB 就找 order 0 的块分配 8KB 就找 order 1。如果对应 order 没空闲块就往更大的 order 找拿一块大的劈成两半这叫分裂释放时如果相邻伙伴块也空闲就合并回更大的块这叫合并。这套机制的精妙在于尽量维持大块连续内存缓解外部碎片。但伙伴系统最小粒度就是 4KB而内核里大量分配请求其实只有几十上百字节比如一个struct file、一个 socket buffer。如果每次都要一整个页浪费会非常可怕。于是有了slab 分配器现在主流实现是 SLUB。它先通过伙伴系统拿整页再把页切成许多同大小的小对象用缓存池管理起来。像kmalloc-64、dentry、inode_cache这些名字就是不同的 slab 缓存。一个实用的观察点是cat /proc/buddyinfo能看每个 zone 各 order 的空闲块数量。如果 order 较高的块全为 0说明连续大内存已经耗尽此时放大页THP、分配大缓冲、甚至创建新进程都可能变慢。而slabtop能按占用排序看 slab 缓存排查内存被内核吃光了时极其有用。我有次遇到内存缓慢增长最后就是靠slabtop定位到某个内核模块的对象缓存没释放。2.3 内存水位内核什么时候开始慌物理内存不是用完才紧张内核设了三道水位线min、low、high。空闲页高于 high一切正常降到 low 以下唤醒后台回收线程kswapd慢慢回收降到 min 以下触发直接回收也就是分配内存的进程自己被迫停下来去回收页面这一步会明显卡顿。如果直接回收也搞不定才轮到 OOM killer 出手。这三道线不是固定值跟 zone 大小有关默认大概是 zone 的 0.1%、0.3%、0.5%受watermark_scale_factor影响。这就解释了一个常见现象为什么内存看着还有不少却已经开始卡。因为空闲页可能已经低于 high 甚至 lowkswapd 在后台拼命干活应用的分配延迟跟着涨。你可以用cat /proc/zoneinfo看到每个 zone 的min/low/high和当前free值两者一对比就知道系统处在哪个档位。注意看到free里 MemFree 很小别急着下结论真正要盯的是/proc/zoneinfo的水位和MemAvailable。MemFree 低但水位健康、MemAvailable 充足通常说明内存被 page cache 占着随时可回收属于正常状态。2.4 复现一次内存充足却被 OOM的现场想彻底理解水位和 OOM最好的办法是自己造一次。思路是开一个内存超卖的环境把vm.overcommit_memory设成 1总是允许超卖然后起多个进程不断申请并触碰内存同时把 swap 关掉。因为地址空间可以被大量承诺但物理页有限当多个进程真的把页写满时水位跌破 min直接回收也回收不出东西都是匿名页且没 swapOOM killer 就会挑一个进程杀掉。这时候你回头看free会发现被杀之前 MemFree 确实不高但更早的时刻可能看着还挺富余——原因就是被承诺的地址空间远大于真实可用的物理页。这个实验不用做得很极端用stress-ng --vm加上合适的 worker 数就能观察到。重点不是把机器搞崩而是亲眼看到/proc/meminfo里Committed_AS一路飙到接近CommitLimit以及dmesg里 OOM 的完整调用栈。看一眼真实的 OOM 日志比读十页文档管用。3. 虚拟内存地址翻译这台机器的内部构造虚拟内存是整套机制的中枢。它管着虚拟地址怎么变成物理地址也管着物理页不够时怎么腾挪。前面说的进程地址空间其实是它的上层接口物理内存是它的底层资源。这一节重点讲清楚翻译过程和缺页处理这是面试高频区也是排查性能问题绕不开的环节。3.1 页表与多级翻译48 位地址是怎么拆的x86_64 上进程用的是 48 位虚拟地址早期实现5 级页表可扩展到 57 位。这 48 位被拆成 5 段PGD 索引 9 位、PUD 9 位、PMD 9 位、PTE 9 位最后 12 位是页内偏移因为一页 4KB 2^12。9×4 12 48正好。每一级页表项指向下一级页表的物理地址最终 PTE 指向真正的物理页帧。这就是多级页表。为什么要多级而不是一张大表算笔账如果单级页表要覆盖 48 位地址空间、按 4KB 页映射需要 2^36 个表项每项 8 字节就是 512GB每个进程一张直接爆炸。多级页表的好处是按需分配进程没用到的地址区间对应的中间页表根本不创建实际开销小得多。代价是翻译要走多级最坏情况访问 4 次内存才能拿到数据——所以才需要 TLB。**TLBTranslation Lookaside Buffer**是 CPU 里的地址翻译缓存缓存最近的虚拟页到物理页映射。命中 TLB 就一步到位未命中才去走页表。进程切换时 TLB 可能失效PCID 技术可以缓解这也是进程切换开销的一部分来源。理解这一点就明白为什么频繁的进程切换对性能不友好。3.2 缺页异常虚拟内存按需兑现的关键动作程序访问一个虚拟地址如果对应的物理页还没建立映射CPU 就会触发缺页异常page fault陷入内核。内核的do_page_fault接手判断这个地址合不合法、该走哪条路径。主要分两种minor fault次缺页页已经在内存里比如在 page cache 中或者父子进程共享的 COW 页只是当前进程的页表项还没建立。内核只要把 PTE 填上指向已有的物理页即可速度较快。major fault主缺页页不在内存需要从磁盘读回来比如从 swap 或映射的文件读。这一步涉及 I/O慢得多是性能分析里要重点关注的指标。还有一种是非法访问地址压根不在任何合法 VMA 里内核直接给进程发 SIGSEGV程序就崩了。你写 C 时空指针解引用收到的段错误走的就是这条路径。缺页异常是按需分页的落地方式。程序malloc一大块内存时内核通常只登记 VMA、并不立刻分配物理页真正第一次写这块内存时才逐页触发缺页、分配物理页。这叫延迟分配。它的好处是省内存——你不用的页永远不会真的给你坏处是内存分配的延迟被平摊到了运行期首次触碰会慢。做性能敏感的应用时提前用memset把内存预热一遍或者用MAP_POPULATE标志让mmap时就把页准备好是很常见的优化手段。注意延迟分配有个副作用就是malloc返回成功不代表真的有内存。如果物理内存和 swap 都不够程序可能在第一次写那块内存时才被 OOM 杀掉而不是在malloc时报错。所以判断内存是否真的可用绝不能只看malloc的返回值。3.3 页面回收与 swap内存不够时的腾挪术物理页不够时内核要选一批页腾出去。它维护LRU 链表分 active 和 inactive又各分匿名页和文件页。回收时优先动 inactive 链表里的页。文件页干净的话可以直接丢弃反正磁盘上还有脏页要先回写匿名页不能直接丢必须写到 swap 里。这里有两个经常被误解的点。第一page cache 占的内存不是浪费它是文件内容的缓存回收时可以直接释放所以内核把它算进可回收内存MemAvailable会把它考虑进去。第二swap 不是洪水猛兽在内存吃紧时它能让系统撑住而不是直接 OOM但它基于磁盘、速度慢几个数量级用多了应用延迟会飙。所以vm.swappiness才有调节空间——它控制内核有多积极地把匿名页换出去默认 60。对于延迟敏感的服务通常会把 swappiness 调低甚至关掉 swap宁愿 OOM 也不要卡在半死状态。主动回收由kswapd负责它静默地干活把空闲页维持在 high 水位附近。当分配快过回收水位跌破 min就进入直接回收此时分配进程被拉着一起干活表现为明显的分配延迟。定位这类问题要看/proc/vmstat里的pgscan_*、pgsteal_*回收扫描/回收量和allocstall_*直接回收停滞。如果allocstall持续增长说明系统已经在内存压力下挣扎了。4. 进程地址空间每个进程看到的那张私人地图前面讲的是内核视角的机制这一节换到进程视角。你写代码时用的每一块内存背后都对应进程地址空间里的一段区间。理解这张地图的布局能帮你解释很多奇怪的现象比如为什么VSZ比RSS大那么多、为什么 fork 之后内存不翻倍。4.1 一张典型的 x86_64 地址空间布局一个 Linux 进程的虚拟地址空间从低到高大体长这样。最底下是代码段text只读可执行往上是数据段含已初始化的 data 和未初始化的 bssbss 在文件里不占空间加载时全部清零再往上是一大块可用区malloc小的内存会通过brk往上顶形成堆然后是很高的地址区间里mmap区域从高往低长动态库、文件映射、匿名大块映射都落在这里最靠近用户空间顶部的是栈从高地址往下增长函数调用、局部变量都放这栈附近还有个特殊的小区域放 vdso/vvar用来加速某些系统调用避免每次gettimeofday都陷入内核。用户空间的上限在 x86_64 上是 0x00007fffffffffff再往上是内核空间0xffff800000000000 起内核空间在所有进程间共享但受页表权限位保护用户态访问不到。4.2 VMA、mmap 与写时复制内核用mm_struct描述一个进程的地址空间用一系列VMAvm_area_struct描述里面每一段连续、属性相同的区间。每个 VMA 记录了这段区间的起始、结束地址、读写执行权限、背后映射的文件如果有等信息。/proc/PID/maps打出来的一行行就是这些 VMA。VMA 的存在让缺页处理变得高效内核拿到一个缺页地址先在 VMA 集合里查这个地址属于哪段、该段有什么属性再决定怎么处理不用每次重新推断。**写时复制COW**是 VMA 层面的一个重要优化。fork创建子进程时内核并不真的复制父进程的全部物理页而是让父子共享同一批页并把它们的 PTE 都设为只读。谁先写谁触发缺页内核这时才给它复制一份独立的页。所以fork之后如果子进程立刻exec几乎不产生物理内存复制即使不 exec只要只读访问也一直共享。这解释了为什么fork一个大进程不一定立刻吃掉双倍内存——真正的复制是写的时候按页发生的。顺带说一句malloc和mmap的关系。glibc 的 malloc 对小于M_MMAP_THRESHOLD默认 128KB动态调整的请求走brk扩展堆对更大的请求直接mmap一块匿名区。所以一个进程里既有堆也可能散落着一堆独立的 mmap 段pmap输出里那些带[anon]的大段就是这么来的。4.3 用 /proc 和 pmap 把地址空间看个透光讲布局太抽象动手看一眼最实在。cat /proc/self/maps能打出当前 shell 运行cat时的地址空间pmap -x pid能给每个映射段列出大小、RSS、脏页。想深入看某段是不是共享、有没有被换出/proc/pid/smaps更细它按段给出Rss、Pss、Shared_Clean、Shared_Dirty、Private_*、Swap等字段。这里要特别说清四个容易混的指标。VSZ是虚拟地址空间大小把没真正分配物理页的映射也算进去所以经常大得离谱。RSS是实际驻留物理内存但共享页会被每个进程重复计算多个进程共享同一份库时数字虚高。PSS把共享页按共享者数量平摊是衡量这个进程真实占用最准的指标。USS是进程独占的那部分。做内存容量规划时看 PSS 比看 RSS 靠谱得多。提示排查内存去哪了时先看RSS找大户再用PSS校正共享库带来的虚高最后用smaps里的Swap确认是否有页被换出。三步下来基本能定位到具体是哪段映射在吃内存。5. 动手实操从观察到验证的完整流程概念讲完得串一遍真实操作。这一节我给一套能直接抄的命令流程用来观察一台机器的内存全貌、盯住某个进程、再亲手复现一次延迟分配。每个命令都说清楚它在看什么、数字代表什么不堆砌。5.1 一套命令摸清整机内存现状第一站永远是/proc/meminfo它是内存的总账本cat /proc/meminfo重点看这几个MemTotal是可用物理内存总量比标称小因为内核和硬件保留了一部分MemFree是完全没用的空闲页MemAvailable是内核估算的不触发 swap 就能拿出来的内存这才是真正该盯的可用值Buffers和Cached是各种缓存其中 Cached 里还包含 tmpfs 占的ShmemDirty是等待回写的脏页Writeback是正在回写的页Slab是内核对象缓存SReclaimable可回收、SUnreclaim不可回收后者异常增长往往意味着内核内存泄漏。换算上有个小细节/proc/meminfo的单位是 KB看的时候除两次 1024 才是 GB。很多人第一次看会误判一个数量级。再看整体压力和缓存情况vmstat 1 5它每秒刷新一次连刷 5 次。si、so是 swap 换入换出非零就说明在动用 swap 了free列对应空闲buff、cache是对应缓存。vmstat的价值在于看趋势而不是看瞬间某一秒数字高不一定是问题持续高才有问题。想看每个 zone 的水位和碎片用cat /proc/zoneinfo | grep -E Node|zone|min|low|high|free cat /proc/buddyinfozoneinfo里的free和水位一对比立刻知道系统处在健康、轻压还是重压buddyinfo看高 order 块还剩多少判断能不能顺利分配大块连续内存。5.2 盯住单个进程RSS、PSS 和缺页选一个目标进程假设 PID 是 1234grep -E VmSize|VmRSS|VmSwap|RssAnon|RssFile /proc/1234/status pmap -x 1234 | tail -n 5status里的VmSize就是 VSZVmRSS是 RSSVmSwap是被换出的量RssAnon是匿名页堆栈这类RssFile是文件页映射的库、文件。pmap -x最后一行给出总和包含 PSSpmap里叫Pss或通过-X看更全。想看缺页频率用ps -o pid,min_flt,maj_flt,cmd -p 1234min_flt、maj_flt分别是次缺页和主缺页的累计次数。想看变化速率就隔几秒再采一次做差。主缺页持续增长说明频繁从磁盘捞页通常是内存不足或访问模式导致缓存命中差。5.3 亲手复现延迟分配和缺页写一小段 C验证malloc 不等于真给内存#include stdio.h #include stdlib.h #include string.h #include unistd.h int main(void) { size_t sz 512UL * 1024 * 1024; // 512MB char *p malloc(sz); if (!p) { perror(malloc); return 1; } printf(malloc 返回检查 RSS\n); sleep(10); // 此时 RSS 基本没涨 memset(p, 1, sz); // 逐页触发缺页真正分配 printf(写入完成检查 RSS\n); sleep(10); free(p); return 0; }编译运行后在两次 sleep 期间分别grep VmRSS /proc/pid/status。你会看到第一次 RSS 很小可能只有几百 KB第二次才涨到 512MB 左右。这就把延迟分配 缺页异常从抽象概念变成了看得见的数字。想进一步看到 minor/major fault 的计数可以在这个程序里读/proc/self/stat或者干脆在终端用/usr/bin/time -v ./a.out它会输出Minor page faults、Major page faults、Maximum resident set size等非常适合做实验记录。5.4 把参数算明白overcommit 与水位很多排查最终要落到参数上这里挑两个最常调的算给你看。先看overcommit_memory和它的配套。当它设为 2严格模式时内核会限制可承诺的地址空间总量CommitLimit SwapTotal (overcommit_ratio / 100) × MemTotal假设机器 16GB 内存、8GB swap、overcommit_ratio默认 50那 CommitLimit 8 0.5×16 16GB。此时如果Committed_AS已承诺的总量逼近 16GB新的malloc或mmap就可能失败哪怕物理内存看着还空。这个计算能解释内存没满但申请大内存失败的诡异现象。再看水位。watermark_scale_factor默认 10水位大致按 zone 管理页数的比例来定min约 0.1%、low约 0.3%、high约 0.5%实际还受watermark_boost_factor等影响。也就是说一个 16GB 的 zonehigh 水位可能是 80MB 左右free 低于这个值 kswapd 就开始干活。调大watermark_scale_factor会抬高水位让回收更早启动适合对分配延迟敏感的机器调小则更激进的利用内存。改之前一定在测试环境验证别直接上生产。6. 常见问题与排查技巧实录前面都是应该是什么样这一节讲实际会出什么幺蛾子。下面整理的每一条都是我或者身边同事真实遇到过的附上排查路径做成速查表方便对号入座。6.1 高频疑问速查表现象常见误解真实原因排查命令free 内存很少内存被吃光了大多是 page cache可回收cat /proc/meminfo看 MemAvailableVSZ 特别大进程占了很多内存虚拟空间包含未分配区pmap -x对比 RSS/PSS多进程 RSS 加起来超过物理内存内存出问题了共享页被重复计数看 PSS 更准内存还多却频繁卡顿硬件问题水位走低直接回收在拖后腿/proc/vmstat看 allocstallmalloc 成功但被 OOMmalloc 没生效延迟分配写入时才要页dmesg看 OOM 栈Slab 持续增长缓存正常工作可能是内核对象泄漏slabtop排序看主缺页一直涨内存不够可能访问模式差或缓存命中低ps -o maj_flt观察用表对照的好处是不用一个个猜。先用现象定位大概方向再用命令确认比上来就top高效得多。6.2 几个我踩过的坑第一个坑是拿MemFree当可用内存。刚工作那会儿看到服务器 MemFree 只剩几百 MB 就慌忙着加内存结果加完发现 MemFree 还是低。后来才明白空闲内存会被内核拿去做缓存这是设计不是故障。判断标准要换成MemAvailable和水位MemFree低本身没有问题。第二个坑是忽略共享内存的重复计数。有一次统计一组进程的总占用把各自的 RSS 加起来发现是物理内存的两倍多以为遇到了内存统计 bug。实际上这些进程大量共享同一批只读库和 tmpfs 页RSS 每个都算了一遍。换成 PSS 累加后就正常了。这件事之后我做容量评估一律以 PSS 为准。第三个坑是随意调大 swap 或者误判 swap 用途。曾经为了防止 OOM给机器加了很大的 swap结果延迟敏感的服务频繁换页监控里 P99 延迟飙得老高。swap 能救急不能救性能延迟敏感场景宁可限制内存用量、做好 OOM 保护也别指望 swap 兜底。第四个坑是没注意 cgroup 的内存限制。容器环境里free显示的是宿主机内存但容器实际受 cgroup 限制。查容器的内存上限要看 cgroup 文件v2 下是/sys/fs/cgroup/memory.max和memory.currentv1 下是/sys/fs/cgroup/memory/memory.limit_in_bytes。容器里的 OOM 和宿主机的 OOM 是两套判断混着看会彻底迷失方向。6.3 给不同类型读者的实操建议如果你是在准备面试重点把缺页异常的两种类型区别多级页表为什么能省内存COW 的工作原理VMA 的作用这几条讲清楚最好能配着自己跑的程序和/proc输出讲比背定义加分。如果你是运维核心是把MemAvailable、zone 水位、vmstat的 si/so、allocstall、cgroup 内存限制这几处盯住再熟练slabtop、pmap、smaps三把看内存的刀。多数线上内存问题靠这套组合就能定位到方向。如果你是应用开发记住三件事就够了malloc成功不等于内存到手大块内存按需触碰、避免一次性猛烈写入造成卡顿容器里别只看free要看 cgroup 限制。把这三条落到代码和部署规范里能省掉一堆半夜被叫起来查内存的麻烦。6.4 把观察常态化而不是出事才查最后分享一个我觉得收益最高的习惯给关键机器配一套常态化的内存观测。不用多复杂一个定时脚本采集/proc/meminfo的MemAvailable、/proc/vmstat的pgscan_kswapd/pgscan_direct、allocstall、/proc/buddyinfo的高 order 剩余跑一段时间就有基线。有了基线异常一眼就能看出来而不是等 OOM 发生才临时抓瞎。我自己在实际操作中的体会是内存问题几乎从不突然发生前面总有水位下滑、直接回收增加、slab 缓慢膨胀这些前兆只是平时没人看。把观察常态化比事后用什么高级工具都管用。这套东西花半天搭起来能一直用下去性价比相当高。如果你对虚拟内存的回收细节感兴趣可以顺着/proc/vmstat里那些pgscan、pgsteal、pgrefill计数器往下挖每个都能对应到内核回收代码里的一段逻辑想搞懂地址翻译的全过程在 QEMU 里跑个内核加 GDB 断在do_page_fault看它一步步填页表比看任何图都快。这条路我走过虽然一开始会有点晕但走通一遍之后Linux 内存管理这些概念就再也不会忘了。 
长河君 · 2026/9/29 14:51:50 · 阅读 1.2k Linux内存管理实战：虚拟内存、物理内存与进程地址空间拆解
前几天线上一个 Java 服务被内核 OOM killer 干掉了运维把截图甩过来free -h里明明还躺着 3 个 G 的 MemFree一堆人第一反应都是内存够啊凭什么杀我进程。这正是Linux 内存管理最反直觉的地方——你以为的空闲内存跟内核真正能立刻掏出来用的内存压根不是一回事。这篇就把 Linux 内存管理里最容易被讲糊的三个核心概念拆开揉碎虚拟内存、物理内存、进程地址空间。不管你是刚装完 Linux 系统、连free输出都看不明白的新手还是准备面试被追问缺页异常到底怎么走的工程师又或者是调服务器时被swappiness、overcommit这些参数绕得头晕的运维都能在下面找到能直接上手的东西。我不打算复述教科书里那套分页机制定义而是沿着内核为什么这么设计、实际跑起来长什么样、出问题拿什么查这条线把每个环节串起来讲。整篇内容偏实战命令都验证过参数都算过账踩过的坑也一并告诉你。1. 先想明白Linux 内存管理到底在管什么在展开细节之前得先把三层这件事立起来。很多人学内存管理学得痛苦根本原因是把三件事混着看物理内存是硬件插在主板上的那几根条子虚拟内存是内核对上层提供的一套地址抽象而进程地址空间是每个进程独享的那份内存地图。这三者层层嵌套物理内存被虚拟内存系统接管虚拟内存又按进程切成一块块地址空间。理解了这个嵌套关系后面所有概念就都有了挂靠点。1.1 为什么一定要有虚拟内存这层中间商假设没有虚拟内存每个进程直接操作物理地址那会立刻冒出三个要命的问题。第一进程之间没有任何隔离A 进程一个野指针就能把 B 进程的数据改掉系统根本谈不上安全。第二内存分配会变成找连续空位的游戏跑久了外部碎片能把 4G 内存碎得连一个 1M 连续块都拼不出来。第三程序编译时必须知道自己会加载到哪个物理地址可实际上每次运行位置都可能变链接器要疯。虚拟内存就是来解决这三个问题的。每个进程都拿到一张独立的虚拟地址空间从 0 一直到用户空间上限看起来整块内存都是我一个人的。进程只管用虚拟地址内核在背后偷偷把虚拟地址翻译成真实物理地址。这样隔离有了进程互相看不见对方的物理页碎片问题缓解了物理页不需要连续只要虚拟页连续就行位置无关也成立了程序永远从固定虚拟地址开始物理位置随便放。我第一次真正开窍是在纸上画了一遍地址翻译流程之后。你会发现虚拟内存这个词其实有两副面孔对应用程序来说它是我拥有的内存对内核来说它是一个需要维护页表来翻译的映射集合。把这两副面孔分清楚很多困惑自己就散了。1.2 三层抽象各自的职责边界物理内存这一层内核要解决的是怎么在大大小小的分配请求之间高效切分真实的 RAM。这里的关键词是伙伴系统、slab 分配器、内存水位。这一层对内普通应用基本碰不到但出问题时最先露馅。虚拟内存这一层内核要解决的是怎么把虚拟地址翻译成物理地址并且在物理页不够时还能撑住。关键词是页表、TLB、缺页异常、按需分页、页面回收、swap。这一层是承上启下的核心。进程地址空间这一层内核要解决的是怎么描述一个进程用了哪些虚拟地址区间、这些区间是什么属性。关键词是VMA、mmap、brk、写时复制。你写 C 程序调malloc、用mmap映射文件动到的就是这一层。三层之间是调用关系进程地址空间描述了要映射什么虚拟内存系统负责把映射建起来并翻译物理内存管理负责真正拿出页来放数据。理清这条链再去看/proc/meminfo、pmap、smaps里的数字就不会觉得它们是一堆无关紧要的计数器了。2. 物理内存内核手里那点真金白银怎么管物理内存是整栋楼的地基虽然应用层看不见但它的管理策略决定了整机在高负载下是稳如老狗还是频繁抖动。这一层最值得动手去看的就是内核把物理内存按什么粒度组织、用什么算法分配、什么时候开始紧张。下面从组织方式讲到实操查看。2.1 NUMA 节点、内存区和页帧的三级组织现代服务器几乎都是 NUMA 架构CPU 访问本地内存节点比访问远端节点快得多。所以内核第一件事就是按 NUMA 节点node把物理内存分组每个 node 内部再按用途划分成不同的 zone。x86_64 上常见的有ZONE_DMA给老式外设用的低地址区、ZONE_DMA32、ZONE_NORMAL普通可用内存、ZONE_MOVABLE可迁移内存用于内存热插拔和大页。zone 这一层存在的意义是不同硬件对地址范围有硬性要求比如某些 DMA 设备只能寻址 16M 以下。再往下zone 被切成一个个固定大小的页帧page frame标准大小 4KB。内核用struct page这个结构体描述每一个物理页帧的状态——是否空闲、被谁引用、是不是脏页。这个结构体本身就要占内存所以 4KB 页的管理开销是实打实存在的。理解管理元数据也要吃内存这一点后面看Slab、PageTables这些字段时就不会惊讶了。组织层次可以简单记成node → zone → page frame。知道这个层级最直接的好处是当你看到numactl --hardware输出多个 node而某个进程只跑在一个 node 上时能立刻意识到可能出现跨 node 访问或内存分配不均的问题。2.2 伙伴系统与 slab两种粒度两种打法内核分配物理页的主力是伙伴系统buddy system。它把空闲页按 2 的幂次分成不同大小的块从 2^0 个页一直到 2^(MAX_ORDER-1) 个页常见 MAX_ORDER 为 11也就是最大 2^10 1024 页约 4MB。分配 4KB 就找 order 0 的块分配 8KB 就找 order 1。如果对应 order 没空闲块就往更大的 order 找拿一块大的劈成两半这叫分裂释放时如果相邻伙伴块也空闲就合并回更大的块这叫合并。这套机制的精妙在于尽量维持大块连续内存缓解外部碎片。但伙伴系统最小粒度就是 4KB而内核里大量分配请求其实只有几十上百字节比如一个struct file、一个 socket buffer。如果每次都要一整个页浪费会非常可怕。于是有了slab 分配器现在主流实现是 SLUB。它先通过伙伴系统拿整页再把页切成许多同大小的小对象用缓存池管理起来。像kmalloc-64、dentry、inode_cache这些名字就是不同的 slab 缓存。一个实用的观察点是cat /proc/buddyinfo能看每个 zone 各 order 的空闲块数量。如果 order 较高的块全为 0说明连续大内存已经耗尽此时放大页THP、分配大缓冲、甚至创建新进程都可能变慢。而slabtop能按占用排序看 slab 缓存排查内存被内核吃光了时极其有用。我有次遇到内存缓慢增长最后就是靠slabtop定位到某个内核模块的对象缓存没释放。2.3 内存水位内核什么时候开始慌物理内存不是用完才紧张内核设了三道水位线min、low、high。空闲页高于 high一切正常降到 low 以下唤醒后台回收线程kswapd慢慢回收降到 min 以下触发直接回收也就是分配内存的进程自己被迫停下来去回收页面这一步会明显卡顿。如果直接回收也搞不定才轮到 OOM killer 出手。这三道线不是固定值跟 zone 大小有关默认大概是 zone 的 0.1%、0.3%、0.5%受watermark_scale_factor影响。这就解释了一个常见现象为什么内存看着还有不少却已经开始卡。因为空闲页可能已经低于 high 甚至 lowkswapd 在后台拼命干活应用的分配延迟跟着涨。你可以用cat /proc/zoneinfo看到每个 zone 的min/low/high和当前free值两者一对比就知道系统处在哪个档位。注意看到free里 MemFree 很小别急着下结论真正要盯的是/proc/zoneinfo的水位和MemAvailable。MemFree 低但水位健康、MemAvailable 充足通常说明内存被 page cache 占着随时可回收属于正常状态。2.4 复现一次内存充足却被 OOM的现场想彻底理解水位和 OOM最好的办法是自己造一次。思路是开一个内存超卖的环境把vm.overcommit_memory设成 1总是允许超卖然后起多个进程不断申请并触碰内存同时把 swap 关掉。因为地址空间可以被大量承诺但物理页有限当多个进程真的把页写满时水位跌破 min直接回收也回收不出东西都是匿名页且没 swapOOM killer 就会挑一个进程杀掉。这时候你回头看free会发现被杀之前 MemFree 确实不高但更早的时刻可能看着还挺富余——原因就是被承诺的地址空间远大于真实可用的物理页。这个实验不用做得很极端用stress-ng --vm加上合适的 worker 数就能观察到。重点不是把机器搞崩而是亲眼看到/proc/meminfo里Committed_AS一路飙到接近CommitLimit以及dmesg里 OOM 的完整调用栈。看一眼真实的 OOM 日志比读十页文档管用。3. 虚拟内存地址翻译这台机器的内部构造虚拟内存是整套机制的中枢。它管着虚拟地址怎么变成物理地址也管着物理页不够时怎么腾挪。前面说的进程地址空间其实是它的上层接口物理内存是它的底层资源。这一节重点讲清楚翻译过程和缺页处理这是面试高频区也是排查性能问题绕不开的环节。3.1 页表与多级翻译48 位地址是怎么拆的x86_64 上进程用的是 48 位虚拟地址早期实现5 级页表可扩展到 57 位。这 48 位被拆成 5 段PGD 索引 9 位、PUD 9 位、PMD 9 位、PTE 9 位最后 12 位是页内偏移因为一页 4KB 2^12。9×4 12 48正好。每一级页表项指向下一级页表的物理地址最终 PTE 指向真正的物理页帧。这就是多级页表。为什么要多级而不是一张大表算笔账如果单级页表要覆盖 48 位地址空间、按 4KB 页映射需要 2^36 个表项每项 8 字节就是 512GB每个进程一张直接爆炸。多级页表的好处是按需分配进程没用到的地址区间对应的中间页表根本不创建实际开销小得多。代价是翻译要走多级最坏情况访问 4 次内存才能拿到数据——所以才需要 TLB。**TLBTranslation Lookaside Buffer**是 CPU 里的地址翻译缓存缓存最近的虚拟页到物理页映射。命中 TLB 就一步到位未命中才去走页表。进程切换时 TLB 可能失效PCID 技术可以缓解这也是进程切换开销的一部分来源。理解这一点就明白为什么频繁的进程切换对性能不友好。3.2 缺页异常虚拟内存按需兑现的关键动作程序访问一个虚拟地址如果对应的物理页还没建立映射CPU 就会触发缺页异常page fault陷入内核。内核的do_page_fault接手判断这个地址合不合法、该走哪条路径。主要分两种minor fault次缺页页已经在内存里比如在 page cache 中或者父子进程共享的 COW 页只是当前进程的页表项还没建立。内核只要把 PTE 填上指向已有的物理页即可速度较快。major fault主缺页页不在内存需要从磁盘读回来比如从 swap 或映射的文件读。这一步涉及 I/O慢得多是性能分析里要重点关注的指标。还有一种是非法访问地址压根不在任何合法 VMA 里内核直接给进程发 SIGSEGV程序就崩了。你写 C 时空指针解引用收到的段错误走的就是这条路径。缺页异常是按需分页的落地方式。程序malloc一大块内存时内核通常只登记 VMA、并不立刻分配物理页真正第一次写这块内存时才逐页触发缺页、分配物理页。这叫延迟分配。它的好处是省内存——你不用的页永远不会真的给你坏处是内存分配的延迟被平摊到了运行期首次触碰会慢。做性能敏感的应用时提前用memset把内存预热一遍或者用MAP_POPULATE标志让mmap时就把页准备好是很常见的优化手段。注意延迟分配有个副作用就是malloc返回成功不代表真的有内存。如果物理内存和 swap 都不够程序可能在第一次写那块内存时才被 OOM 杀掉而不是在malloc时报错。所以判断内存是否真的可用绝不能只看malloc的返回值。3.3 页面回收与 swap内存不够时的腾挪术物理页不够时内核要选一批页腾出去。它维护LRU 链表分 active 和 inactive又各分匿名页和文件页。回收时优先动 inactive 链表里的页。文件页干净的话可以直接丢弃反正磁盘上还有脏页要先回写匿名页不能直接丢必须写到 swap 里。这里有两个经常被误解的点。第一page cache 占的内存不是浪费它是文件内容的缓存回收时可以直接释放所以内核把它算进可回收内存MemAvailable会把它考虑进去。第二swap 不是洪水猛兽在内存吃紧时它能让系统撑住而不是直接 OOM但它基于磁盘、速度慢几个数量级用多了应用延迟会飙。所以vm.swappiness才有调节空间——它控制内核有多积极地把匿名页换出去默认 60。对于延迟敏感的服务通常会把 swappiness 调低甚至关掉 swap宁愿 OOM 也不要卡在半死状态。主动回收由kswapd负责它静默地干活把空闲页维持在 high 水位附近。当分配快过回收水位跌破 min就进入直接回收此时分配进程被拉着一起干活表现为明显的分配延迟。定位这类问题要看/proc/vmstat里的pgscan_*、pgsteal_*回收扫描/回收量和allocstall_*直接回收停滞。如果allocstall持续增长说明系统已经在内存压力下挣扎了。4. 进程地址空间每个进程看到的那张私人地图前面讲的是内核视角的机制这一节换到进程视角。你写代码时用的每一块内存背后都对应进程地址空间里的一段区间。理解这张地图的布局能帮你解释很多奇怪的现象比如为什么VSZ比RSS大那么多、为什么 fork 之后内存不翻倍。4.1 一张典型的 x86_64 地址空间布局一个 Linux 进程的虚拟地址空间从低到高大体长这样。最底下是代码段text只读可执行往上是数据段含已初始化的 data 和未初始化的 bssbss 在文件里不占空间加载时全部清零再往上是一大块可用区malloc小的内存会通过brk往上顶形成堆然后是很高的地址区间里mmap区域从高往低长动态库、文件映射、匿名大块映射都落在这里最靠近用户空间顶部的是栈从高地址往下增长函数调用、局部变量都放这栈附近还有个特殊的小区域放 vdso/vvar用来加速某些系统调用避免每次gettimeofday都陷入内核。用户空间的上限在 x86_64 上是 0x00007fffffffffff再往上是内核空间0xffff800000000000 起内核空间在所有进程间共享但受页表权限位保护用户态访问不到。4.2 VMA、mmap 与写时复制内核用mm_struct描述一个进程的地址空间用一系列VMAvm_area_struct描述里面每一段连续、属性相同的区间。每个 VMA 记录了这段区间的起始、结束地址、读写执行权限、背后映射的文件如果有等信息。/proc/PID/maps打出来的一行行就是这些 VMA。VMA 的存在让缺页处理变得高效内核拿到一个缺页地址先在 VMA 集合里查这个地址属于哪段、该段有什么属性再决定怎么处理不用每次重新推断。**写时复制COW**是 VMA 层面的一个重要优化。fork创建子进程时内核并不真的复制父进程的全部物理页而是让父子共享同一批页并把它们的 PTE 都设为只读。谁先写谁触发缺页内核这时才给它复制一份独立的页。所以fork之后如果子进程立刻exec几乎不产生物理内存复制即使不 exec只要只读访问也一直共享。这解释了为什么fork一个大进程不一定立刻吃掉双倍内存——真正的复制是写的时候按页发生的。顺带说一句malloc和mmap的关系。glibc 的 malloc 对小于M_MMAP_THRESHOLD默认 128KB动态调整的请求走brk扩展堆对更大的请求直接mmap一块匿名区。所以一个进程里既有堆也可能散落着一堆独立的 mmap 段pmap输出里那些带[anon]的大段就是这么来的。4.3 用 /proc 和 pmap 把地址空间看个透光讲布局太抽象动手看一眼最实在。cat /proc/self/maps能打出当前 shell 运行cat时的地址空间pmap -x pid能给每个映射段列出大小、RSS、脏页。想深入看某段是不是共享、有没有被换出/proc/pid/smaps更细它按段给出Rss、Pss、Shared_Clean、Shared_Dirty、Private_*、Swap等字段。这里要特别说清四个容易混的指标。VSZ是虚拟地址空间大小把没真正分配物理页的映射也算进去所以经常大得离谱。RSS是实际驻留物理内存但共享页会被每个进程重复计算多个进程共享同一份库时数字虚高。PSS把共享页按共享者数量平摊是衡量这个进程真实占用最准的指标。USS是进程独占的那部分。做内存容量规划时看 PSS 比看 RSS 靠谱得多。提示排查内存去哪了时先看RSS找大户再用PSS校正共享库带来的虚高最后用smaps里的Swap确认是否有页被换出。三步下来基本能定位到具体是哪段映射在吃内存。5. 动手实操从观察到验证的完整流程概念讲完得串一遍真实操作。这一节我给一套能直接抄的命令流程用来观察一台机器的内存全貌、盯住某个进程、再亲手复现一次延迟分配。每个命令都说清楚它在看什么、数字代表什么不堆砌。5.1 一套命令摸清整机内存现状第一站永远是/proc/meminfo它是内存的总账本cat /proc/meminfo重点看这几个MemTotal是可用物理内存总量比标称小因为内核和硬件保留了一部分MemFree是完全没用的空闲页MemAvailable是内核估算的不触发 swap 就能拿出来的内存这才是真正该盯的可用值Buffers和Cached是各种缓存其中 Cached 里还包含 tmpfs 占的ShmemDirty是等待回写的脏页Writeback是正在回写的页Slab是内核对象缓存SReclaimable可回收、SUnreclaim不可回收后者异常增长往往意味着内核内存泄漏。换算上有个小细节/proc/meminfo的单位是 KB看的时候除两次 1024 才是 GB。很多人第一次看会误判一个数量级。再看整体压力和缓存情况vmstat 1 5它每秒刷新一次连刷 5 次。si、so是 swap 换入换出非零就说明在动用 swap 了free列对应空闲buff、cache是对应缓存。vmstat的价值在于看趋势而不是看瞬间某一秒数字高不一定是问题持续高才有问题。想看每个 zone 的水位和碎片用cat /proc/zoneinfo | grep -E Node|zone|min|low|high|free cat /proc/buddyinfozoneinfo里的free和水位一对比立刻知道系统处在健康、轻压还是重压buddyinfo看高 order 块还剩多少判断能不能顺利分配大块连续内存。5.2 盯住单个进程RSS、PSS 和缺页选一个目标进程假设 PID 是 1234grep -E VmSize|VmRSS|VmSwap|RssAnon|RssFile /proc/1234/status pmap -x 1234 | tail -n 5status里的VmSize就是 VSZVmRSS是 RSSVmSwap是被换出的量RssAnon是匿名页堆栈这类RssFile是文件页映射的库、文件。pmap -x最后一行给出总和包含 PSSpmap里叫Pss或通过-X看更全。想看缺页频率用ps -o pid,min_flt,maj_flt,cmd -p 1234min_flt、maj_flt分别是次缺页和主缺页的累计次数。想看变化速率就隔几秒再采一次做差。主缺页持续增长说明频繁从磁盘捞页通常是内存不足或访问模式导致缓存命中差。5.3 亲手复现延迟分配和缺页写一小段 C验证malloc 不等于真给内存#include stdio.h #include stdlib.h #include string.h #include unistd.h int main(void) { size_t sz 512UL * 1024 * 1024; // 512MB char *p malloc(sz); if (!p) { perror(malloc); return 1; } printf(malloc 返回检查 RSS\n); sleep(10); // 此时 RSS 基本没涨 memset(p, 1, sz); // 逐页触发缺页真正分配 printf(写入完成检查 RSS\n); sleep(10); free(p); return 0; }编译运行后在两次 sleep 期间分别grep VmRSS /proc/pid/status。你会看到第一次 RSS 很小可能只有几百 KB第二次才涨到 512MB 左右。这就把延迟分配 缺页异常从抽象概念变成了看得见的数字。想进一步看到 minor/major fault 的计数可以在这个程序里读/proc/self/stat或者干脆在终端用/usr/bin/time -v ./a.out它会输出Minor page faults、Major page faults、Maximum resident set size等非常适合做实验记录。5.4 把参数算明白overcommit 与水位很多排查最终要落到参数上这里挑两个最常调的算给你看。先看overcommit_memory和它的配套。当它设为 2严格模式时内核会限制可承诺的地址空间总量CommitLimit SwapTotal (overcommit_ratio / 100) × MemTotal假设机器 16GB 内存、8GB swap、overcommit_ratio默认 50那 CommitLimit 8 0.5×16 16GB。此时如果Committed_AS已承诺的总量逼近 16GB新的malloc或mmap就可能失败哪怕物理内存看着还空。这个计算能解释内存没满但申请大内存失败的诡异现象。再看水位。watermark_scale_factor默认 10水位大致按 zone 管理页数的比例来定min约 0.1%、low约 0.3%、high约 0.5%实际还受watermark_boost_factor等影响。也就是说一个 16GB 的 zonehigh 水位可能是 80MB 左右free 低于这个值 kswapd 就开始干活。调大watermark_scale_factor会抬高水位让回收更早启动适合对分配延迟敏感的机器调小则更激进的利用内存。改之前一定在测试环境验证别直接上生产。6. 常见问题与排查技巧实录前面都是应该是什么样这一节讲实际会出什么幺蛾子。下面整理的每一条都是我或者身边同事真实遇到过的附上排查路径做成速查表方便对号入座。6.1 高频疑问速查表现象常见误解真实原因排查命令free 内存很少内存被吃光了大多是 page cache可回收cat /proc/meminfo看 MemAvailableVSZ 特别大进程占了很多内存虚拟空间包含未分配区pmap -x对比 RSS/PSS多进程 RSS 加起来超过物理内存内存出问题了共享页被重复计数看 PSS 更准内存还多却频繁卡顿硬件问题水位走低直接回收在拖后腿/proc/vmstat看 allocstallmalloc 成功但被 OOMmalloc 没生效延迟分配写入时才要页dmesg看 OOM 栈Slab 持续增长缓存正常工作可能是内核对象泄漏slabtop排序看主缺页一直涨内存不够可能访问模式差或缓存命中低ps -o maj_flt观察用表对照的好处是不用一个个猜。先用现象定位大概方向再用命令确认比上来就top高效得多。6.2 几个我踩过的坑第一个坑是拿MemFree当可用内存。刚工作那会儿看到服务器 MemFree 只剩几百 MB 就慌忙着加内存结果加完发现 MemFree 还是低。后来才明白空闲内存会被内核拿去做缓存这是设计不是故障。判断标准要换成MemAvailable和水位MemFree低本身没有问题。第二个坑是忽略共享内存的重复计数。有一次统计一组进程的总占用把各自的 RSS 加起来发现是物理内存的两倍多以为遇到了内存统计 bug。实际上这些进程大量共享同一批只读库和 tmpfs 页RSS 每个都算了一遍。换成 PSS 累加后就正常了。这件事之后我做容量评估一律以 PSS 为准。第三个坑是随意调大 swap 或者误判 swap 用途。曾经为了防止 OOM给机器加了很大的 swap结果延迟敏感的服务频繁换页监控里 P99 延迟飙得老高。swap 能救急不能救性能延迟敏感场景宁可限制内存用量、做好 OOM 保护也别指望 swap 兜底。第四个坑是没注意 cgroup 的内存限制。容器环境里free显示的是宿主机内存但容器实际受 cgroup 限制。查容器的内存上限要看 cgroup 文件v2 下是/sys/fs/cgroup/memory.max和memory.currentv1 下是/sys/fs/cgroup/memory/memory.limit_in_bytes。容器里的 OOM 和宿主机的 OOM 是两套判断混着看会彻底迷失方向。6.3 给不同类型读者的实操建议如果你是在准备面试重点把缺页异常的两种类型区别多级页表为什么能省内存COW 的工作原理VMA 的作用这几条讲清楚最好能配着自己跑的程序和/proc输出讲比背定义加分。如果你是运维核心是把MemAvailable、zone 水位、vmstat的 si/so、allocstall、cgroup 内存限制这几处盯住再熟练slabtop、pmap、smaps三把看内存的刀。多数线上内存问题靠这套组合就能定位到方向。如果你是应用开发记住三件事就够了malloc成功不等于内存到手大块内存按需触碰、避免一次性猛烈写入造成卡顿容器里别只看free要看 cgroup 限制。把这三条落到代码和部署规范里能省掉一堆半夜被叫起来查内存的麻烦。6.4 把观察常态化而不是出事才查最后分享一个我觉得收益最高的习惯给关键机器配一套常态化的内存观测。不用多复杂一个定时脚本采集/proc/meminfo的MemAvailable、/proc/vmstat的pgscan_kswapd/pgscan_direct、allocstall、/proc/buddyinfo的高 order 剩余跑一段时间就有基线。有了基线异常一眼就能看出来而不是等 OOM 发生才临时抓瞎。我自己在实际操作中的体会是内存问题几乎从不突然发生前面总有水位下滑、直接回收增加、slab 缓慢膨胀这些前兆只是平时没人看。把观察常态化比事后用什么高级工具都管用。这套东西花半天搭起来能一直用下去性价比相当高。如果你对虚拟内存的回收细节感兴趣可以顺着/proc/vmstat里那些pgscan、pgsteal、pgrefill计数器往下挖每个都能对应到内核回收代码里的一段逻辑想搞懂地址翻译的全过程在 QEMU 里跑个内核加 GDB 断在do_page_fault看它一步步填页表比看任何图都快。这条路我走过虽然一开始会有点晕但走通一遍之后Linux 内存管理这些概念就再也不会忘了。