Linux内存分配器全解析：glibc malloc、slab与OOM排查

1. 从一个"内存只涨不降"的进程说起

做服务端运维和后台开发的人，多半都遇到过这种场景：top里某个进程的 RES 一栏从 200M 慢慢爬到 1.5G，业务请求量明明没变，重启一下又回到 200M，过两天再爬上去。第一次遇到，直觉是内存泄漏，于是上工具查，结果发现堆上的对象数量稳定，没有任何东西被漏掉。这时候问题就不在业务代码了，而在更底层的linux 内存分配器上。

内存分配器是一层"中间商"，夹在应用程序和内核之间。你调用malloc(32)，真正发生的事情远不止"分配 32 字节"这么简单：用户态分配器先从自己手里的一块大内存里切一小块给你，切不出来的时候才向内核申请一批页，内核再去找物理页框，找不到还要回收、压缩甚至触发 OOM。整条链路上每一层都有自己的策略、缓存、碎片问题。标题写的是"linux内存分配器"，但它其实是一个多层体系，从上到下至少包括用户态的 glibc malloc / jemalloc / tcmalloc，以及内核态的 slab 家族、伙伴系统、vmalloc。只盯着其中一层看，很多现象是解释不通的。

这篇内容适合三类人：一是写过 C/C++ 服务、被malloc行为坑过的后端开发；二是天天和容器内存限制、OOM Killer 打交道的运维；三是准备linux面试题、想真正搞懂"malloc 背后发生了什么"的同学。我不打算把它写成手册式的 API 罗列，而是按我自己的排查顺序来：先讲清楚每一层在干什么、为什么这么设计，再给可复现的观测命令和测试代码，最后把我踩过的坑摊开说。里面的参数和阈值都来自实际环境，你在自己机器上照着敲一遍，基本能对上号。

1.1 内存分配器到底在解决什么问题

如果只有内核，没有用户态分配器，程序每次要几字节内存都得走一次系统调用，代价太高。一次系统调用的开销大致在几百纳秒到微秒量级，而一次用户态的指针运算只要几纳秒，差了两三个数量级。所以分配器的第一使命就是批量取货、零售发货：一次性向内核要一大块，之后所有小请求都在这块内存里切，切到不够了再补货。

第二个使命是对抗碎片。假设你不停申请释放 16 字节、64 字节、256 字节的对象，如果每次都去内核要页，物理内存很快会被切成无数小洞：明明总空闲量还有 500M，但连一个连续的 4K 页都凑不出来。分配器通过把相近大小的对象归到同一个缓存池、通过空间换时间的策略，把碎片控制在一个可接受的范围内。

第三个使命是多线程下的伸缩性。单线程时代，一个全局锁加一个空闲链表就够了；多核时代，16 个线程同时malloc，如果共用一把锁，锁竞争会成为瓶颈。于是出现了 per-thread cache、arena 分片、无锁队列等各种设计。glibc 的 arena 机制、jemalloc 的 tcache 分桶，本质上都是在拆锁、拆竞争。

理解这三件事，后面所有的参数和现象就都有了解释的锚点：为什么 free 了内存 RSS 不降（缓存没还给内核），为什么多线程程序内存涨得比预期快（每个线程有自己的缓存池），为什么容器里明明还有空闲内存却触发了 OOM（限制算的是 cgroup 内的总用量，不是物理机的）。

1.2 内核态与用户态的两套分配体系

最容易混淆的一点是：内核里也有个"内存分配器"，但它和用户态的完全是两套东西，服务的对象、粒度、约束都不一样。用户态分配器管的是进程虚拟地址空间里的字节级分配，内核分配器管的是物理页框和内核数据结构。

分层带来的好处是各司其职：伙伴系统只处理 2 的幂次的页块，算法简单高效；slab 负责把页框切成小对象，减少内部碎片；用户态分配器负责高频小请求，避开系统调用。坏处是信息不透明——free之后内存去了哪一层缓存、什么时候会真正还回内核，全部由各层自己决定，你在应用层看不到。

我排查内存问题的习惯是从下往上：先看/proc/buddyinfo判断物理页碎片，再看/proc/slabinfo看内核对象占用，最后才用malloc_stats看进程堆。顺序反了容易在用户态绕半天，结果发现是内核某个驱动在猛吃 slab。下面就把这几层逐个拆开讲。

2. 内核分配器拆解：伙伴系统与 slab 家族

2.1 伙伴系统如何管理物理页框

伙伴系统（buddy allocator）是内核物理页分配的地基，思路非常朴素：把所有空闲页框按 2 的幂次大小分组，每组叫一个阶（order）。order 0 是 1 个页（4K），order 1 是 2 个页，order 2 是 4 个页，一直到 order 10（4M）甚至更高。要分配 8K，就找 order 1 的空闲块；找不到，就去 order 2 的链表里拿一块，劈成两半，一半给你，另一半挂回 order 1 链表。这两半互为"伙伴"。释放的时候反过来，如果伙伴也空闲，就合并成更大块，一层层往上合。

这个设计的关键收益是合并高效，因为伙伴地址可以通过异或运算直接算出来：buddy = addr ^ (1 << (order + PAGE_SHIFT))，不用遍历链表。代价是只支持 2 的幂次，分配 3 个页的需求会退化成 4 个页，产生内部碎片。

/proc/buddyinfo是观测它的窗口，输出大概是这个样子：

$ cat /proc/buddyinfo Node 0, zone DMA 1 1 1 0 2 1 1 0 1 1 3 Node 0, zone DMA32 1234 2345 1234 567 234 123 45 12 3 1 0 Node 0, zone Normal 23456 12345 6789 3456 1234 567 234 89 12 2 0

每个数字是对应 order 的空闲块个数，从左到右 order 0 到 10。看这张表有个经验：如果前面几列（order 0-3）数字很大，后面几列全是 0，说明内存碎得厉害，大块连续内存已经很难拿到了。反过来如果是 order 10 和 order 9 有数，说明大块内存充足。我遇到过一次内核模块加载失败报-ENOMEM，物理内存明明有 20G 空闲，看 buddyinfo 才发现 order 8 以上全是 0，拿不到连续的大块，最后重启解决。这类问题在长时间运行、频繁分配释放的机器上尤其常见。

2.2 slab、slub、slob 三种实现的取舍

伙伴系统最小粒度是一个页 4K，但内核里有大量比 4K 小得多的对象：一个task_struct几 KB，一个dentry一百多字节，一个inode几百字节。如果每个都单独占一页，浪费极大。slab 分配器就是来解决这个问题的：它从伙伴系统拿整页，切成固定大小的小块，同类对象共用一个缓存（cache），这样既减少碎片，又能复用已经初始化好的对象，缓存命中率也更高。

内核里其实有三套实现，编译时选一套：

• slab：最早的一版，每个 cache 有多个 slab（由一页或多页组成），每个 slab 有完整的管理结构和 per-CPU 缓存。功能最全，但管理数据本身占内存，结构复杂。
• slub：现在主流发行版的默认选择。它砍掉了大量冗余元数据，管理结构直接塞进页描述符，一个 cache 通常只有少量 slab，per-CPU 的 freelist 让分配几乎无锁。整体更省内存、扩展性更好。
• slob：给内存极其有限的嵌入式场景用的，算法简单、代码量小，牺牲了性能换体积。资源受限的嵌入式设备上能见到。

具体的指标可以用/proc/slabinfo看，第二列是每个对象的字节数，第三列是活跃对象数：

$ sudo cat /proc/slabinfo | sort -k3 -nr | head -8 kmalloc-192 12345 13568 192 21 1 : tunables ... : slabdata 646 646 0 dentry 45678 48256 192 21 1 : tunables ... : slabdata 2298 2298 0 inode_cache 23456 24640 576 7 1 : tunables ... : slabdata 3520 3520 0

sort -k3 -nr是按活跃对象数倒序排，看谁占用最多。这里要提醒一个误区：slabinfo里的对象数是当前活着的对象，不是历史累计，别把它当成泄漏指标。真正判断是否有泄漏，要隔几分钟看两次，活跃对象数持续单调上升才值得怀疑。kmalloc-192、kmalloc-256这种按大小命名的 cache 对应的是kmalloc系列，驱动里临时申请的小块内存基本都落在这里。

提示：在 cgroup v1 时代，slab 的一部分占用不计入容器内存限制，导致"容器 OOM 了但看不到谁在吃内存"。cgroup v2 已经把这部分纳入统计，如果你还在用 v1，排查时要额外留意。

2.3 kmalloc、vmalloc 与用户态映射的边界

内核里拿内存有几个常用入口，用错场景会付出不必要的代价：

核心原则一句话：DMA 必须用物理连续内存（kmalloc或alloc_pages），因为设备 DMA 引擎直接操作物理地址；而纯粹给 CPU 访问的大块缓冲，用vmalloc更稳，因为不需要赌物理内存的连续性，碎片严重的机器上也不会轻易失败。我在一个老系统上见过驱动申请 2MB 的 DMA 缓冲反复失败，就是因为长期运行后 order 9 的空闲块没了，最后改成开机预留才解决。

这里还有个容易被忽略的点：vmalloc分配出来的虚拟地址区间是逐页映射的，每次分配都要改页表，释放要及时，否则 vmalloc 区耗尽会报vmalloc: allocation failure。内核里 vmalloc 的虚拟空间是有限的（历史上 32 位系统只有 128M 左右，64 位宽松很多但也不是无限）。所以"能不用 vmalloc 就不用"是内核开发的常识。

3. 用户态分配器：glibc malloc 的三本账

3.1 chunk、bin、arena 到底指的是什么

把视线拉回应用层。你在 C 程序里写malloc(24)，glibc 返回的指针前面其实藏着一个头部结构，叫 chunk header，记录着这块内存的大小和状态位。所谓 chunk，就是"真正占用堆内存的单元"，用户看到的指针永远指向 chunk 的数据区，而不是头部。理解这一点很重要，因为free(p)时 glibc 是靠p往回推固定偏移找到头部的，所以只能释放 malloc 系列返回的指针，你自己偏移过的指针传进去必然崩。

bin 是"回收站"的集合。释放掉的 chunk 不会立刻还给内核，而是按大小挂到不同的 bin 上，下次同样大小的请求可以直接从这里拿。glibc 的 bin 分几类：fastbin 管 32 到 128 字节左右的小块，是单链表、先进后出，速度最快；smallbin 管到 512 字节左右，双向链表、先进先出；largebin 管更大的，内部还有按大小排序的逻辑；unsorted bin 是"中转站"，释放的大块先扔这儿，下次分配时先来这里翻一遍，能靠合并减少碎片。这套设计说白了就是用分类换速度。

arena 则是"分仓"。单线程时代用主 arena 就够，多线程一上来，所有人抢一把锁会打成死结。glibc 的方案是：主线程用主 arena，其他线程按需创建新的 arena，每个 arena 有自己的 bin、自己的堆段。默认上限是8 * CPU核数（在 64 位系统上），这样 8 核机器最多 64 个 arena，32 线程的进程基本一个线程一个，锁竞争大幅下降。

但代价也来了：每个 arena 都要独立向内核要内存，而且释放后不一定归还。一个 32 线程的程序，如果每个线程各创建一个 arena，每个 arena 缓存 64M，就是 2G 的虚拟和驻留内存，哪怕实际活跃数据只有几 M。这就是"线程越多内存涨得越快"的根因。控制手段有两个：环境变量MALLOC_ARENA_MAX直接卡住 arena 数量，或者用mallopt(M_ARENA_MAX, n)在代码里设。

3.2 brk 与 mmap 两条取内存的路径

glibc 向内核要内存有两条路。第一条是brk/sbrk，把进程堆的顶部指针往上推，适合"连续增长"的分配需求。第二条是mmap，映射一块独立的匿名内存区域，适合大块分配。

分界线由M_MMAP_THRESHOLD控制，默认是 128KB（注意：这个值会随释放行为动态调整，最大到 32MB）。小于这个阈值的分配走 brk，从堆里切；大于的走 mmap，直接映射一块。为什么要分开？因为大块内存如果从堆中间切，释放后容易留下大洞（堆顶指针降不下来，中间的空间又没法还给内核），而 mmap 的块释放后munmap一调用，内存立刻还给系统，干净利落。

M_TRIM_THRESHOLD管的是另一件事：堆顶有超过这个量（默认 128KB）的空闲空间时，free会调用brk把堆顶还回去。这两个阈值直接决定了你看到的现象：

• free了内存但 RSS 不掉：多半是释放的 chunk 在堆中间或者被 arena 缓存着，够不到 trim 的条件。
• RSS 剧烈波动：mmap 阈值的动态调整在起作用，程序一会儿走 brk 一会儿走 mmap。

实测中，MALLOC_MMAP_THRESHOLD_=131072和MALLOC_TRIM_THRESHOLD_=131072这两个环境变量能把行为固定下来，方便复现和对比。但要注意，把 mmap 阈值调低会让大量小分配走 mmap，系统调用次数暴涨，性能会掉，所以除非有明确的碎片问题，别乱动。

3.3 jemalloc 与 tcmalloc 的差异化设计

glibc malloc 的这些问题，催生了两个替代品。jemalloc最早是 FreeBSD 项目里的实现，后来被大量互联网服务采用。它的核心改进是大小类（size class）划分更细 + 每线程缓存更激进：所有小请求被归到约 40 个大小类里，每个线程有独立的缓存，几乎不用加锁；arena 和 chunk 的管理也更规整，碎片率明显低于 glibc。缺点是小对象的内部碎片略高（比如请求 33 字节会给你 48 字节的类），以及内存占用绝对值可能更大。

tcmalloc走的是另一条路：核心是 Thread Cache + Central Free List + Page Heap 三级结构，小对象从线程本地缓存拿，不够了再从中央列表批量补货，中央列表不够再从页堆拿。它对大对象的处理比 glibc 更平滑，且自带 heap profiler，抓内存泄漏很方便。很多大型 C++ 服务默认链的就是它。

对比一下三者在典型 Web 服务上的表现，我做过一轮简单压测（4 核 8G，QPS 5000 左右的长连接服务）：

数字因业务而异，别直接抄结论，但趋势是稳的：高并发多线程服务换成 jemalloc 或 tcmalloc，通常能同时改善内存和延迟。换法也简单，LD_PRELOAD挂上去就行：

# 先确认库里有哪些符号 nm -D /usr/lib/x86_64-linux-gnu/libjemalloc.so.2 | grep malloc # 挂载到已有程序启动命令前 LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 ./your_service # 或者在编译期直接链接 gcc main.c -o app -ljemalloc

注意：LD_PRELOAD挂载的库必须在程序启动时就存在，容器镜像里要提前 COPY 进去。另外某些程序自己实现了 malloc 包装（比如内存审计工具），两层 preload 的顺序会打架，排查时先用ldd和/proc/<pid>/maps确认到底加载了哪一个。

4. 动手观测：把内存分配过程看清楚

4.1 从 /proc 文件系统读内存快照

排查内存问题，/proc是信息最全的地方，而且不用装任何工具。几个高频文件：

# 全局内存概况，重点看 MemTotal / MemAvailable / Slab / SReclaimable cat /proc/meminfo # 物理页碎片，看各 order 的空闲块分布 cat /proc/buddyinfo # 内核 slab 占用，按活跃对象排序 sudo sort -k3 -nr /proc/slabinfo | head -20 # 单个进程的映射区，判断大概谁占了内存 sudo cat /proc/$(pgrep your_service)/maps | awk '{print $2, $6}' | sort | uniq -c | head # 进程级内存明细，比 top 更细 sudo cat /proc/$(pgrep your_service)/smaps_rollup

smaps_rollup特别值得推荐，它比smaps轻量得多，一次读就能拿到整个进程的 Pss、Rss、Shared、Private 汇总。想知道"进程的内存具体在哪几段"，用它比top靠谱得多。我一般会先看它，如果 Pss 远小于 Rss，说明大部分是共享库；如果 Private 很大，才是自己进程独占的堆内存。

另外pmap -x <pid>能把每个映射区的大小、RSS、脏页一列列打出来，配合sort -k3 -nr一排序，一眼就能看出哪块最大。这个方法我在排查"某进程占了 8G 但业务只用了 1G"这类问题时用得最多，十次有八次能定位到是某个缓存没有上限，或者某个 arena 膨胀了。

4.2 进程级追踪：mtrace、malloc_stats、malloc_info

除了看文件，glibc 自己也提供了几个追踪接口，不用额外工具。

第一个是malloc_stats()，在代码里调用一次，会把当前 arena 的总大小、实际使用量、系统分配量打到 stderr：

#include <malloc.h> // 在你想观测的地方插入 malloc_stats(); // 输出类似： // Arena 0: // system bytes = 2097152 // in use bytes = 786432 // Total (incl. mmap): // system bytes = 2097152 // in use bytes = 786432 // max mmap regions = 1 // max mmap bytes = 131072

system bytes是向内核要的总量，in use bytes是用户实际持有的量，两者的差就是缓存和碎片。差越大，浪费越多。如果这个差值持续扩大而不收敛，基本可以定性为分配器层面的膨胀，而不是业务泄漏。

第二个是malloc_info()，它输出 XML 格式的详细统计，包含每个 arena、每个 bin 的空闲块分布，适合做定时采样和趋势分析。第三个是mtrace()，在程序开头调mtrace()，退出时用mtrace命令解析MALLOC_TRACE指定的日志文件，能精确到"哪一行代码分配的内存没释放"。用法：

gcc -g -o app app.c MALLOC_TRACE=./trace.log ./app mtrace ./app ./trace.log # 报告里的每一行都对应源码位置

在mtrace之前，务必把编译优化降到-O0 -g，否则行号对不上，报告会误导你。

4.3 一段可复现的分配压测代码

光看文档不直观，写段代码跑一遍，所有现象都能对上号：

// alloc_probe.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <malloc.h> int main(void) { printf("=== 场景一：小对象反复申请释放 ===\n"); malloc_stats(); for (int i = 0; i < 100000; i++) { void *p = malloc(64); // 全部走 fastbin 路径 free(p); } malloc_stats(); // 这里 system bytes 基本不变，in use 归零 printf("=== 场景二：跨阈值的大块分配 ===\n"); void *big[10]; for (int i = 0; i < 10; i++) { big[i] = malloc(256 * 1024); // 超过 128K，走 mmap memset(big[i], 0, 256 * 1024); // 触碰每一页，确保物理内存真分配 } malloc_stats(); // 这里 max mmap regions 会涨到 10 for (int i = 0; i < 10; i++) free(big[i]); malloc_stats(); // munmap 后 system bytes 应明显回落 printf("=== 场景三：中间切洞导致 trim 失效 ===\n"); void *a = malloc(1024 * 1024); void *b = malloc(4096); void *c = malloc(1024 * 1024); memset(a, 1, 1024 * 1024); memset(c, 1, 1024 * 1024); free(c); // c 在堆中间，brk 降不下来，RSS 不降 free(a); free(b); // 全部释放，堆顶才可能 trim malloc_stats(); return 0; }

编译运行：

gcc -O0 -g alloc_probe.c -o alloc_probe ./alloc_probe 2>&1 | tee /tmp/stat.log

跑完对照输出看，你会发现场景一的system bytes几乎不动，因为 fastbin 完全吃下了这些小块；场景二的 mmap 区域数从 0 涨到 10，释放后回落；场景三即使全部 free 了，RSS 也不一定降回去，因为 glibc 认为这些内存以后还会用。把这三段理解透，日常 80% 的内存困惑都能自己解释。

5. 高频故障与排查实录

5.1 RSS 只涨不降与内存碎片

这是被问得最多的现象。free之后 RSS 不降，通常有三个层次的原因，需要依次排除：

第一层，内存还在分配器手里。glibc 把释放的 chunk 挂在 bin 上，等待下次复用，没有调用brk或munmap还回去。这不是泄漏，是缓存策略。判断方法就是上面的malloc_stats，看system bytes - in use bytes的差值。

第二层，碎片导致还不了。要还内存给内核，必须是堆顶的一整段空闲区。如果堆顶正好有个未释放的小对象卡着，中间再多的空闲 chunk 也还不了。这就是场景三演示的问题。缓解办法是控制大块分配走 mmap（调低M_MMAP_THRESHOLD），避免大块碎片卡在堆中间。

第三层，进程根本没能力还。比如用了自定义内存池、对象缓存，池子只扩不缩，那再多工具也看不出分配器的问题。这时候要去看代码里的池子容量管理。

排查顺序我建议固定成：pmap -x看哪段大，smaps_rollup看私有内存量，malloc_stats看分配器差值，最后才怀疑代码。顺序对了，通常半小时内能定位。

5.2 OOM Killer、cgroup 与容器内存限制

容器里跑程序，另一个高频问题是"物理机还有一半内存空闲，容器却被 OOM Killer 杀了"。原因在于容器内存限制是cgroup 层面的，看的不是物理机空闲量，而是本 cgroup 内所有进程的匿名内存 + 页缓存 + 内核内存的合计。

几个容易踩的点：

• page cache 也算。容器里大量读写文件，page cache 会把内存吃掉，达到限制时内核先回收 cache，回收不动才触发 OOM。所以有时容器跑着跑着 RSS 没涨，反而被杀了，其实是 cache 惹的祸。
• 每个线程的栈也算。默认栈 8M（虚拟，实际按需），但线程多了，虚拟地址空间和一定的物理占用都上来了。
• arena 多寡影响很大。32 线程的进程如果放开 arena，每个 arena 独立缓存，很容易把限制撑爆。容器里我通常会显式设MALLOC_ARENA_MAX=4。
• cgroup v1 的统计口径不同。slab 的一部分在内核早期版本不计入容器限制，现在虽然修了，但如果你跑在老内核上，观察结果会和预期不一致。

定位 OOM 的入口是内核日志：

dmesg -T | grep -i "killed process" grep -i "oom" /var/log/messages 2>/dev/null | tail

输出里会明确列出被杀进程的 total-vm、rss、pgtables 等指标，对照着看是哪一项超了。如果是 cgroup 限制触发的，还会有Memory cgroup out of memory字样，日志里能直接看到限制值和当前用量。

5.3 常见问题速查表

把排查中反复出现的现象整理成表，出问题时先对号入座：

这张表不是万能的，但它能帮你跳过最容易走弯路的阶段。真正排查时，我最常用的组合是：smaps_rollup+malloc_stats+dmesg，三样东西基本覆盖了九成场景。

6. 调优参数与工程经验

6.1 值得掰开讲的几个环境变量

glibc malloc 的行为可以通过一批环境变量在不改代码的前提下调整，部署时直接加在启动脚本里就行。

# 限制 arena 数量，容器和服务端最常用 export MALLOC_ARENA_MAX=4 # 固定 mmap 阈值，大块分配一律走 mmap，便于回收 export MALLOC_MMAP_THRESHOLD_=131072 # 固定 trim 阈值，堆顶空闲超过 128K 就还给内核 export MALLOC_TRIM_THRESHOLD_=131072 # 关掉每线程 arena，全部用主 arena（适合线程多但分配量小的场景） export MALLOC_ARENA_TEST=1 # 打印每次 mmap / trim 的调用，调试用 export MALLOC_TRACE=/tmp/mtrace.log

这里最需要权衡的是MALLOC_ARENA_MAX。调小它可以显著降低多线程程序的内存占用，但会增加锁竞争；调大则相反。经验值是：线程数少于 8 的服务，设 2 到 4 就够；线程数几十上百、分配又密集的服务，设2*CPU比默认的8*CPU更平衡。我的做法是先跑基线，再逐档压测，看内存和 QPS 的曲线拐点在哪，别凭感觉拍一个数。

还有个冷门但有用的技巧：如果你的服务有明显的"空闲期"（比如夜间流量低），可以在空闲期主动调一次malloc_trim(0)，把堆顶的空闲内存还给内核。这个系统调用开销不大，定时任务里每分钟跑一次完全没问题。实测下来，一个每天涨 200M 的服务加上这个操作后，RSS 曲线变成了锯齿状，最大值稳定了。

#include <malloc.h> // 在定时任务的回调里调用 malloc_trim(0);

6.2 踩坑之后总结的几条经验

第一条，别看到 RSS 涨就断定泄漏。先区分"分配器缓存"和"业务持有"，工具就是malloc_stats。我见过太多团队在这个判断上浪费了一周，最后发现是 arena 缓存。

第二条，换分配器是成本最低的优化。如果一个服务内存和延迟都不理想，LD_PRELOAD挂 jemalloc 只需要改一行启动命令，风险可控，收益往往立竿见影。前提是先用压测验证，别直接上生产。

第三条，容器里的内存限制要留足余量。cgroup 限制设得太贴边，page cache 一波动就 OOM。我的习惯是按稳态峰值的 1.5 倍设，同时把MALLOC_ARENA_MAX压住，两头一起管。

第四条，观测要连续，不能只看一眼。内存问题很多是趋势性的，单次快照说明不了什么。我一般会写个每小时采样smaps_rollup和slabinfo的小脚本，把结果落盘画曲线，回看时升级、流量、定时任务这些变量才能对上号。

第五条，也是我吃亏最多的一条：内核层的碎片问题，很多时候只能靠重启或预留大页解决。这不是设计缺陷，是长期运行的必然。所以我给关键服务配了定期滚动重启，这不是偷懒，是承认物理内存碎片管理的边界。能靠工程手段绕开的，就别去写一堆复杂的回收逻辑硬扛。