Linux怎么查看具体的进程私有内存占用详细报告

USS（Unique Set Size）是进程真正独占的物理内存，等于/proc/[pid]/smaps中Private_Clean与Private_Dirty之和，排除共享页，比VmRSS更准确反映进程实际内存开销。

查 /proc/[pid]/smaps 得到 USS（私有内存）精确值

USS（Unique Set Size）才是进程实实在在“独占”的物理内存，它等于 Private_Clean 与 Private_Dirty 之和。它把所有共享页（比如libc、JVM共享库）都排除在外，相较于 VmRSS 而言，更能准确反映“这个进程实际占用了多少内存”。要获取USS，最权威的来源就是直接读取 /proc/[pid]/smaps，内核会实时更新这里的数据，不需要依赖用户态工具进行解析。

操作方式很简单：

• 先拿到目标 PID，例如：pgrep -f "python app.py"
• 执行：awk '/^Private_Clean|^Private_Dirty/ {sum += $2} END {print sum " kB"}' /proc/PID/smaps
• 或者用更稳妥的写法（兼容空行或字段偏移）：grep -E '^(Private_Clean|Private_Dirty):' /proc/PID/smaps | awk '{sum += $2} END {print sum " kB"}'

注意：Private_Clean 和 Private_Dirty 单位是 kB，不是字节；如果某段没出现（比如无脏页），对应字段会缺失，所以不能硬写 $2 索引，必须按行匹配关键词。

pmap -x 显示各内存段的私有/共享属性

pmap -x 不直接标出“私有”或“共享”，但它输出的 RSS 列是每段实际驻留内存，而 MMAP 类型字段（如 [heap]、[anon]、[stack]）基本都是私有段；libxxx.so 或可执行文件路径段则大概率共享。关键看 Kbytes 和 RSS 是否接近——若 RSS 远小于 Kbytes，说明该段大量页未加载或被换出，但只要 RSS > 0，这部分就算进 USS。

典型私有段包括：

• [heap]：堆分配，100% 私有
• [stack]：主线程栈，私有
• [anon]：匿名映射（如 malloc/mmap(MAP_ANONYMOUS)），私有
• .data、.bss 段（在 ELF 映射中 rw-p 权限那行）：通常私有

运行 pmap -x PID 后，最后一行的 RSS 总和 ≈ VmRSS，但无法直接拆出 USS；要算 USS，仍需回退到 smaps 解析。

为什么不用 ps 或 top 的 RSS？

ps 的 RSS 和 top 的 RES 都等价于 VmRSS —— 它是进程所有驻留页总和，含共享库页。比如 10 个 Ja va 进程都用了同一份 libjvm.so，每个进程的 RSS 都把这份内存重复计入，加起来远超物理内存总量。

这就导致两个问题：

• 误判单个进程真实开销（尤其容器环境里资源限制按 USS 算）
• 排查内存泄漏时，RSS 持续上涨但找不到增长源头（其实是共享库被其他进程触发加载）

所以当你要回答“这个进程到底占了多少没人能抢走的内存”，RSS 是错的指标，USS 才是答案。

别跳过 smaps 里的 MMUPageSize 和 MMUPageSize 细节

/proc/[pid]/smaps的每个内存段后面，或许会跟着MMUPageSize与MMAPPageSize这两个字段，它们揭示了大页（huge page）的使用状况。倘若某一段显示为MMUPageSize: 2048 kB，那就表明它采用了2MB大页，这对于内存碎片以及TLB命中率的影响极大——不过更为关键的是：大页的Private_Clean和Private_Dirty是按照整页来统计的，哪怕仅仅修改了一个字节，整个2MB页都会被计入Private_Dirty。

这意味着：

• USS 数值可能比预期“毛刺化”，尤其在频繁 mmap 小块内存又启用大页的场景下
• 看到 USS 突增 2MB，不一定是有新分配，可能是某个已有大页首次变脏
• 检查是否启用透明大页：cat /proc/sys/vm/transparent_hugepage/enabled

这个细节常被忽略，但它解释了为什么 USS 曲线有时阶梯式跳变，而不是平滑增长。