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 更贴近“这个进程实际吃掉多少内存”。直接读 /proc/[pid]/smaps 是最权威的来源，内核实时更新，不依赖用户态工具解析。
操作方式很简单：
- 先拿到目标 PID，例如：
pgrep -f "python app.py" - 执行：
awk '/^Private_Clean|^Private_Dirty/ {sum += $2} END {print sum " kB"}' /proc/<code>PID/smaps - 或者用更稳妥的写法（兼容空行或字段偏移）：
grep -E '^(Private_Clean|Private_Dirty):' /proc/<code>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 <code>PID 后，最后一行的 RSS 总和 ≈ VmRSS，但无法直接拆出 USS；要算 USS，仍需回退到 smaps 解析。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
为什么不用 ps 或 top 的 RSS？
ps 的 RSS 和 top 的 RES 都等价于 VmRSS —— 它是进程所有驻留页总和，含共享库页。比如 10 个 Java 进程都用了同一份 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 曲线有时阶梯式跳变，而不是平滑增长。
