RSS 和 %MEM 是最常用也最易误解的内存指标：RSS 表示进程实际占用的物理内存（KB），%MEM 是其占系统总物理内存的百分比；VSZ/VIRT 不反映真实内存压力，VmRSS 与 RSS/RES 严格一致，USS 才是关停进程后可回收的独占内存。
直接看 ps 或 top 就能快速得到进程内存占用的统计值，但要注意字段含义和排序方式——RSS 和 %MEM 是最常用、也最容易误解的两个指标。
ps aux --sort=-%mem 看全局内存占比
这是脚本化或快速排查时最实用的命令。它输出所有进程的静态快照，按内存使用百分比倒序排列：
-
%MEM是进程 RSS 占系统总物理内存的百分比，不是绝对值；如果系统内存扩容了，同一进程的%MEM会变小 -
RSS（Resident Set Size）才是实际占用的物理内存 KB 数，等价于RES列（在top中） - 别用
VSZ判断真实内存压力——它包含已分配但未使用的虚拟内存、mmap 映射、swap 预留等，可能远大于 RSS - 加
| head -n 10只看前 10 名，避免刷屏；加-u username可限定用户范围
top -p PID 实时盯住单个进程
适合观察某个进程内存是否持续增长（比如怀疑泄漏时）：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 启动后按
M键，确保按%MEM排序，再用o过滤出目标PID或命令名 - 重点关注
RES列（即 RSS），单位是 KB；VIRT高但RES稳定，通常没问题 - 注意
SHR（共享内存）是否异常高——可能是大量共享库加载，也可能是多个子进程共用同一段内存，此时单看RES会高估实际开销 - 如果
RES持续上涨且不回落，配合pmap -x PID看堆段（[heap]）是否膨胀，再查代码逻辑
/proc/PID/status 读取精确的 VmRSS 值
当需要脚本提取或验证其他工具结果时，这是最权威的来源：
- 执行
grep VmRSS /proc/1234/status，输出类似VmRSS: 123456 kB，这个值和ps的RSS、top的RES严格一致 - 不要用
VmSize（对应VIRT）来评估真实内存压力 -
MemAvailable在/proc/meminfo里，反映系统整体可分配内存，和单个进程无关，但可辅助判断是否真缺内存 - 注意：PID 不存在或权限不足时会报
No such file or directory，需确认进程仍在运行且你有读取/proc/PID/的权限
smem 更准地统计 USS（独占内存）
当多个进程共享同一库（如 Python 解释器、JVM）时，RSS 会重复计算——smem 能拆解出真正属于该进程的私有内存：
- 安装后运行
smem -p -P nginx或smem -c "pid name uss rss pss"，其中USS=Private_Clean + Private_Dirty，代表进程独占的物理内存 -
PSS（Proportional Set Size）把共享内存按引用计数均摊，更适合横向比较同类进程的“人均开销” -
smem依赖/proc/PID/smaps，某些精简版内核或容器环境可能默认禁用该接口，会提示Permission denied或空输出 - 没有 root 权限时，
smem只能查看自己启动的进程；ps和top则受限更小
真正容易被忽略的是：同一个进程的 RSS 在不同时间点波动几十 MB 很正常（例如 glibc malloc 的 arena 扩缩），但持续单向增长才值得深挖；而 USS 才是你关停这个进程后，系统能真正回收的内存量。
