如何在Linux利用Pmap-X分析特定中间件进程在内存中的物理分页分布

要分析中间件物理分页分布，需结合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 ，若报 或无 列，说明内核未启用 或 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）： CentOS Linux 7.9.2009 CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。 下载 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() 锁住，不会换出，来源固定，需检查是否超出 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 场景）