真实物理内存占用应看 rss（resident set size），单位 kb，反映当前驻留 ram 的物理页大小；pss 更准确体现进程独占与分摊的内存，避免共享库重复计算。
ps 命令怎么看真实物理内存占用？
ps 默认显示的 %MEM 和 VSZ 容易误导——前者是占总内存百分比，但基于虚拟内存（VSZ），后者本身不含实际物理页信息。真正反映物理内存消耗的是 RSS（Resident Set Size），即当前驻留在 RAM 中的物理页大小。
-
RSS单位是 KB，不是 MB；显示值不含共享库重复计算，但包含所有私有匿名页 + 已映射且实际加载的共享库页 - 要看某个进程的 RSS：
ps -o pid,rss,comm -p <code>PID</code>
- 想按 RSS 降序查前 10：
ps -eo pid,rss,comm --sort=-rss | head -n 11
- 注意：
RSS会把共享内存段（如 tmpfs、shm）也算进去，如果进程大量使用/dev/shm，RSS 会虚高，但确实是物理内存占用
pmap 怎么确认某进程的物理内存分布？
pmap 不直接输出“物理内存总量”，而是列出每个内存段的映射详情，其中 MMAP 行末尾的 pages 列（如 123456K）才是该段当前实际驻留的物理内存大小。关键要看带 ---p 权限且非 [anon] 的共享段是否被重复计入。
- 查看某进程所有映射及物理页占用：
pmap -x <code>PID</code>
输出中RES列就是该段的物理内存（KB），最后一行total是粗略 RSS 总和（与ps的RSS基本一致，但不含内核栈等隐式部分） - 若发现某
.so库的RES异常高，可能是该进程触发了其大量代码/数据页加载，而非其他进程共享导致 -
pmap -XX <code>PID可显示更细粒度的页类型（如 anon、file、shared），但需内核开启CONFIG_PROC_PAGE_MONITOR，多数发行版默认关闭
为什么 ps RSS 和 top 中 RES 经常不一致？
这不是 bug，而是统计口径差异：top 的 RES 默认包含部分缓存页（如 page cache 中被该进程最近访问过的文件映射页），而 ps 的 RSS 严格只计已分配且未换出的用户态物理页。
- 同一时刻运行
ps -o pid,rss -p <code>PID</code>
和top -b -n1 -p <code>PID</code> | grep <code>PID</code>
，数值可能差几 MB - 这种差异在频繁读写大文件的进程（如数据库、压缩工具）上最明显
- 真实物理压力应以
/proc/<code>PID/statm 第二列为准（单位为页），它和ps RSS最接近：awk '{print $2 * 4}' /proc/<code>PID</code>/statm
别忽略 /proc/PID/smaps 里的 PSS
RSS 会重复计算共享库，比如 10 个 Java 进程共用同一套 JRE，RSS 把每份都算一遍。真正衡量“这个进程独占+分摊的物理内存”要用 PSS（Proportional Set Size）。
- 查单个进程总 PSS（KB）：
awk '/^Pss:/ {sum += $2} END {print sum}' /proc/<code>PID</code>/smaps -
PSS对容器内存限制、多实例部署容量规划更真实 - 但注意：
smaps解析开销大，高频轮询会影响性能；生产环境慎用脚本反复扫
RSS 是运维快速定位内存大户的第一把手，PSS 才是资源核算的底线。共享库越重、进程越多，两者差距越大——盯着 RSS 做扩容，可能多买一倍内存。
