pmap无法记录内存分配失败历史，因它仅提供静态快照；内核默认不记录va碎片导致mmap/malloc失败的日志，仅统一返回enomem，需通过pmap -x结合地址间隙分析和/proc/[pid]/maps最大空闲段推断碎片问题。
pmap 无法查看内存分配失败记录，它只读快照，不记录历史事件
Linux 内核本身不默认记录“因地址空间碎片导致 mmap/malloc 失败”的具体日志。这类失败通常表现为应用层 malloc 返回 NULL 或 mmap 返回 MAP_FAILED，但内核不会主动写入日志说明“此处因碎片无法合并出 2MB 连续 VA”。你看到的往往是结果，不是原因。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
为什么 dmesg 和 /var/log/messages 里找不到碎片失败日志
内核对虚拟内存分配失败（尤其是 ENOMEM）的处理非常克制：
- ENOMEM 可能来自物理内存不足、RLIMIT_AS 超限、或 VA 空间碎片，但内核统一返回错误码，不区分根源
- 除非触发 OOM killer，否则 dmesg 不输出分配失败细节；OOM 日志也只说 “Out of memory: Kill process”，不提“无法找到连续 1GB VA”
- /proc/[pid]/maps 和 pmap 是静态快照，反映当前映射，不包含“刚才尝试分配但失败了哪几段”的痕迹
真正能间接推断 VA 碎片问题的两个实操信号
- 用
pmap -x [pid]输出 +sort -k1n查看地址间隙：重点关注[anon]和[heap]周围是否存在大量小块空洞（比如一堆 4KB–64KB 的未使用区域夹在大段之间） - 检查
/proc/[pid]/maps中最大连续空闲 VA 区域：awk '$1 ~ /^([0-9a-f]+)-([0-9a-f]+)$/ { split($1, a, "-"); gap = "0x" a[2] - "0x" a[1]; if (gap > max) max = gap } END { print max " bytes" }' /proc/[pid]/maps—— 若最大空闲段远小于应用请求 size（如请求 512MB，但最大空闲仅 8MB），就是强碎片信号
排查时最容易被忽略的关键点
碎片问题常被误判为“内存泄漏”，因为 pmap -x 里 RSS 没涨，但 Kbytes（虚拟地址占用）持续增长且分布零散。这时候要盯住 Kbytes 列总和，而不是只看 RSS；还要注意 [vdso]、[vvar] 等内核映射是否异常增多——某些老内核在频繁 clone() 后会残留不可回收的 vvar 映射，直接吃掉低地址空间。
