pmap 不显示物理内存占用，因为它仅读取虚拟内存映射信息（/proc/PID/maps），而内核不向用户空间暴露物理页帧号，且物理内存动态共享、换入换出；可用 pmap -x 或 /proc/PID/smaps 查看 RSS、Pss 等近似指标。
pmap 本身无法直接显示“真实物理内存占用”，它只报告进程的虚拟内存映射（VMA）信息，包括各段的虚拟地址范围、权限、映射文件等。Linux 内核不向用户空间暴露每个虚拟页对应的物理页帧号（PFN），且物理内存是动态共享、换入换出、延迟分配的，因此没有一个静态、精确、实时的“各段物理占用”数字能被 pmap 或普通用户工具直接给出。
为什么 pmap 不显示物理内存占用
• pmap 读取 /proc/PID/maps 和 /proc/PID/smaps，前者只含虚拟布局，后者虽含 Rss、Pss、Swap 等统计，但仍是按内存区域聚合的近似值，不是按段逐页的物理映射快照
• 物理页可能被多个进程共享（如共享库、fork 后的 COW 页面），Rss 会重复计算，Pss 做了权重折算，但依然无法定位到某段地址对应哪些具体物理页
• 内核为性能和安全考虑，不提供用户态访问物理页帧号的接口（需 root + kernel module + /dev/mem 或 eBPF 才可能间接推断，且极不推荐）
可用的替代方案：获取接近“物理占用”的关键指标
• 使用 pmap -x PID 查看扩展信息：输出包含 RSS（Resident Set Size，当前驻留物理内存字节数）、Dirty（脏页大小）、Mode（读写执行权限）等列，可粗略判断哪段更“重”
• 解析 /proc/PID/smaps 获取每段详细统计：
– 每个 VMA 区域后跟一组键值对，重点关注：
Rss: 该段实际占用的物理内存（KB）
Pss: 按共享比例折算后的物理内存（KB），更适合多进程场景评估
Referenced: 被最近访问过的物理页数（反映活跃度）
MMUPageSize / MMUPageSize: 实际使用的页大小（4K/2M/1G），影响 TLB 效率
• 用 cat /proc/PID/smaps_rollup 快速获得全进程汇总（Rss、Pss 总和）
进阶：定位高 RSS 段并分析原因
• 先用 pmap -x PID | sort -k3 -nr | head -10 找 RSS 最大的前几段
• 结合 /proc/PID/maps 查看该段映射来源：
– 若为 [heap]：堆内存膨胀，检查 malloc/new 泄漏或大对象缓存
– 若为 [anon]（无名映射）：可能是 mmap(MAP_ANONYMOUS) 分配，如 jemalloc/mimalloc 的 arena 或 Go runtime 的 span
– 若为共享库路径（如 /lib/x86_64-linux-gnu/libc.so.6）：正常，但若 RSS 异常高，可能该库被大量修改（COW 后变私有）
• 配合 smaps 中的 MMUPageSize 判断是否启用大页——大页 Rss 更稳定，但浪费更明显
真正需要物理页帧？谨慎考虑可行性
• 普通调试完全不需要知道物理地址。优化重点应是降低 RSS/Pss、减少缺页中断、避免过度分配
• 如确需物理页信息（如硬件驱动验证、极端性能调优），必须：
– 运行在特权模式（root）
– 加载自定义内核模块或使用 eBPF（如 bpftrace 跟踪 page-fault 路径）
– 读取 /proc/PID/pagemap（需开启 CONFIG_PROC_PAGE_MONITOR），再结合 /proc/kpageflags 解析，但结果仍是瞬时快照，且受锁、并发、页面回收影响极大
• 对绝大多数应用开发者，关注 Rss、Pss、Referenced 和 Swap 已足够指导内存优化
