USS是杀进程后实际释放的内存，PSS反映物理内存真实占用，RSS因重复计算共享内存易误判；smem通过USS/PSS精准定位内存大户，比top/ps更准。
直接看 USS 和 PSS，别信 RSS —— 它会把共享内存重复计算，容易误判“谁吃掉了内存”。
为什么 smem 比 top / ps 更准
top 里显示的 RES（即 RSS）是进程驻留内存总和，包含所有共享库、mmap 映射段。比如 10 个 python 进程共用同一份 libc.so，RSS 会把这段内存算 10 遍；而 PSS 把它均摊，USS 则完全剔除共享部分。
真实场景下：
- 杀掉一个 Chrome 渲染进程，实际释放多少内存？看它的
USS - 对比两个服务哪个更“重”？用
PSS排序更公平 - 发现某进程
USS接近RSS，说明它几乎没共享内存——大概率在缓存私有数据或泄漏
快速定位内存大户：smem -s pss -r
这条命令是排查的起点，按 PSS 降序列出所有进程：
smem -s pss -r
常用组合：
- 只看前 5 名：
smem -s pss -r -n 5 - 加单位（MB/GB）：
smem -s pss -r -k -n 5 - 排除内核线程（减少干扰）：
smem -s pss -r -k -n 5 | grep -v '\[.*\]'
注意：-s pss 是关键，-r 表示倒序（最大在前），-k 启用缩写单位（K/M/G），不加的话默认字节，数字大得吓人但没意义。
查某个应用的总内存：smem -P 正则 + -t
浏览器、Java 服务常拆成多个子进程，ps 或 top 看单个 PID 容易漏掉。用 -P 按名称匹配再求和：
smem -c "pss" -P "^java" -k -t | tail -n 1
说明：
-
-P "^java"匹配以java开头的进程名（^是正则锚点，避免匹配到javascript） -
-c "pss"只输出PSS列（不是pss，大小写敏感） -
-t输出汇总行，tail -n 1取最后一行即总数
常见陷阱：-P chrome 会匹配 chrome、chromium、chrome-sandbox，若只想看主进程，用 -P "^chrome$" 或 -P "^chrome-bin$" 更精准。
识别共享异常：smem -m 对比 USS/PSS 差距
smem -m 显示系统级内存映射（如 /usr/lib/x86_64-linux-gnu/libc-2.31.so、[anon]），能帮你判断共享是否健康：
- 如果某
[anon]映射的PSS很高，但USS≈RSS，说明它基本没被共享——可能是某个进程 malloc 了大量独占内存未释放 - 若
libQt5Core.so.5的PSS总和远小于其RSS × 进程数，说明共享效率高，不是瓶颈 - 配合
smem -p -c "pid comm uss pss rss"找出USS / PSS > 0.9的进程，优先检查它们的内存行为
真正容易被忽略的是：USS 才是你 kill 之后能立刻回收的量；PSS 总和才接近物理内存真实占用——这两项不看，光盯着 RSS，等于拿错尺子量体重。
