要分析中间件物理分页分布，需结合pmap -x定位关键段、pmap -xx溯源分页属性（需内核支持config_proc_page_monitor且procps-ng≥3.3.17）、再通过/proc/[pid]/smaps下钻验证mmupagesize、locked、swap及shared_clean/private_dirty等真实分页行为。
直接用 pmap -x 无法看到物理分页分布，它只显示虚拟内存区域的驻留页总量（RSS），不揭示页大小、锁定状态、交换归属或是否共享等底层分页属性。要分析中间件进程（如 Nginx、Redis、Kafka Broker）在内存中的物理分页分布，核心是结合 pmap -x 定位可疑段 + pmap -XX 溯源分页来源 + /proc/[pid]/smaps 下钻验证。
先确认 -XX 模式是否可用
中间件常驻运行，PID 稳定，适合深度分析。但 -XX 不是默认开启功能：
- 执行 pmap -XX 1 | head -5，若报
invalid option或无MMUPageSize列，说明内核未启用CONFIG_PROC_PAGE_MONITOR或 procps-ng 版本过低（需 ≥ 3.3.17） - 检查 grep MMUPageSize /proc/1/smaps，有输出才支持 -XX
- 常见可用环境：Ubuntu 22.04+、RHEL 9+/CentOS Stream 9、Debian 12+，内核 ≥ 5.10
用 pmap -x 快速圈定中间件的关键内存段
以 Redis 为例（PID=1234）：
- pmap -x 1234 | grep -E '\[heap\]|\[anon\]|\.so|redis' —— 聚焦堆、匿名映射、共享库和主程序本身
- 重点关注 RSS 值大的 [anon] 行：Redis 的 AOF 缓冲、复制积压缓冲区、Lua 脚本内存池都走 mmap(MAP_ANONYMOUS)，若某 [anon] RSS 从 16MB → 128MB 持续上涨，就是物理分页增长源头
- 对比多个 [anon] 行的 Kbytes 和 RSS：若 Kbytes=1024000（1GB 虚拟空间）但 RSS=32，说明仅分配了 32KB 物理页，属稀疏映射；若 RSS 接近 Kbytes，说明物理页已密集填充
对重点段用 -XX 查物理分页属性
找到可疑地址段后，用 -XX 看分页级细节：
- pmap -XX 1234 | awk '$1 ~ /^00007f/ && $NF ~ /\[anon\]/ {print}' —— 提取高地址匿名段的 -XX 输出
- MMUPageSize = 2048 → 该段使用 2MB 大页，大概率是透明大页（THP）或显式 hugetlb 映射，物理分页粒度粗、TLB 效率高
-
Locked > 0 → 这部分物理页被 mlock() 锁住，不会换出，来源固定，需检查是否超出
RLIMIT_MEMLOCK - Swap > 0 且持续上升 → 物理页正被内核回收并写入 swap，说明系统内存压力大，该段实际物理页正在迁移
下钻 smaps 验证分页行为真实性
-XX 是汇总视图，最终判断必须查原始数据：
- 取 -XX 输出中某行 Address（如 00007f8b2c000000），运行：
grep -A 10 "00007f8b2c000000" /proc/1234/smaps - 看 Shared_Clean 和 Private_Dirty：若前者为 0、后者高达 16MB，说明该段虽标为共享（Mode 含 s），但所有写操作都触发了写时复制（COW），实际已变成私有物理页 —— 这就是“伪共享”，物理分页完全由本进程独占
- 看 MMUPageCount × MMUPageSize 是否 ≈ RSS × 1024 → 若严重偏小，说明存在大量未映射的虚拟地址空洞；若远大于，可能涉及嵌套页表（如容器中 KVM 场景）
