smem 查进程内存应重点关注 USS 和 PSS：USS 是进程独占物理内存，PSS 为共享内存分摊值，两者相加更接近真实占用；推荐命令 smem -s pss -r -c "pid uss pss rss command" 按 PSS 倒序展示关键指标。
直接用 smem 查进程的实际内存消耗，关键不是看 RSS，而是盯住 USS 和 PSS——USS 是进程真正独占的物理内存，PSS 是它“应分摊”的共享内存部分，两者加起来才接近真实占用。
查单个进程的精确内存（推荐 USS + PSS）
运行以下命令，按 PSS 从高到低排序，显示每个进程的 USS、PSS、RSS 和命令名：
smem -s pss -r -c "pid uss pss rss command"- 加
-r表示倒序（最大在前），-c指定列，避免冗余信息干扰判断 - 重点关注 USS：比如某个 Java 进程 USS 是 120MB，说明它独自占用了 120MB 物理内存，这部分不会被其他进程分摊
- PSS 更适合横向对比总负载：若两个 Chrome 标签页共享 80MB 的 V8 库，PSS 会把这 80MB 平均分给它们，各算 40MB
快速定位高耗内存进程（带过滤）
不想翻屏？用正则快速筛出目标进程：
- 查 nginx 相关进程：
smem -P 'nginx' -s pss -r -c "pid uss pss rss name" - 查所有 Python 进程：
smem -P 'python' -s uss -r（按 USS 排，揪出真正吃内存的那一个） - 加
-p可显示百分比，方便一眼看出某进程占系统总内存的比例
按用户维度汇总（识别谁在拖慢系统）
多个用户共用一台服务器时，用这个看资源归属：
-
sudo smem -u -p -s pss（必须加sudo才能统计全部用户） - 输出中每行是一个用户名，PSS 总和代表该用户所有进程「公平分摊」后的内存占用
- 配合
smem -u -p -s uss对比，能看出该用户是否大量启动独立进程（USS 高），还是集中跑几个共享型服务（PSS 明显高于 USS）
验证结果是否合理（避免误判）
USS 小但 PSS 大？可能是进程加载了大量共享库；USS 和 PSS 都异常高？大概率存在内存泄漏或缓存未释放：
- 用
smem -p -c "name uss pss" | head -10看前 10 名，再单独查可疑进程的内存映射：smem -p -m | grep -A5 -B5 'java' - 对比
ps aux --sort=-%mem | head -5和smem -s pss -r | head -5，如果排名差异大，说明 RSS 已严重失真，此时 smem 的 PSS 更可信
