ps命令最直接查看RSS，单位为KB；/proc/PID/status中VmRSS最准确；RSS反映实际驻留物理内存，但含共享页，总和常超物理内存总量。
ps 命令看 RSS 最直接，但要注意单位和默认字段
Linux 下最常用的是 ps，它能快速列出进程的物理内存占用。关键不是看所有字段，而是明确你要的是「实际驻留物理内存」——也就是 RSS（Resident Set Size）。ps 默认不显示 RSS，得手动指定：
-
ps aux --sort=-rss：按 RSS 降序排列，RSS列单位是 KB（不是字节，也不是 MB） -
ps -eo pid,ppid,cmd,%mem,rss --sort=-rss：自定义输出，含 PID、父进程、命令、内存百分比、RSS 值 - 注意：
%mem是基于系统总物理内存算的百分比，但分母不含 swap，也不含内核内存，所以加起来可能不到 100%
top 和 htop 显示 RSS 更直观，但 htop 默认不标单位
top 启动后按 Shift + M 可按内存使用排序，默认显示的 RES 就是 RSS（单位 KB）。htop 更友好，但要注意：
-
htop的MEM%列是 RSS 占总物理内存比例，但它的RES列默认无单位，需进入 Setup（F2）→ Columns → 确认RES字段已启用且理解其值为 KB -
htop不显示 VSS，也没法直接切到 VSS 排序；若需要对比 VSS，仍得回ps或/proc/PID/status - 某些发行版的
htop编译时没开MEMORY_PERCENTAGE支持，MEM%可能恒为 0 —— 此时只能信RES数值
/proc/PID/status 里找 VmRSS 和 VmSize，这是最准的来源
所有用户态进程的内存细节都暴露在 /proc/PID/status 中，这里的数据不经过格式化或舍入，是内核原始统计：
-
VmRSS对应 RSS，单位是 KB；VmSize对应 VSS（Virtual Memory Size），也是 KB - 例如：
grep -E 'VmRSS|VmSize' /proc/1234/status，其中 1234 是目标进程 PID - VSS 包含所有映射的虚拟地址空间：代码段、数据段、共享库、malloc 分配但未 touch 的页、mmap 的文件或匿名区域……哪怕这些页根本没加载进物理内存，也算进 VSS
- RSS 是 VSS 的子集，只计当前真正驻留在 RAM 中的页框数；但 RSS 可能包含共享页（如多个进程共用同一 libc），所以所有进程 RSS 加总通常 > 物理内存总量
别把 RSS 当“进程独占内存”，共享页和缓存会让它失真
RSS 常被误读为“这个进程吃掉了这么多物理内存”，其实不是：
- 多个进程共享的动态库（如
libc-2.31.so）只在物理内存存一份，但每个进程的 RSS 都计入这部分 —— 所以 RSS 总和远超可用内存很正常 - 文件映射（
mmap）的干净页（clean page）被换出后，RSS 会下降，但 VSS 不变；而脏页（dirty page）即使被写回磁盘，只要没释放映射，RSS 仍可能保留 - 内核无法区分“RSS 中哪些页可立即回收”，所以
free -h的available值 ≠ 总内存 − 所有 RSS 之和；它还考虑了 page cache、slab、可回收的 dentry/inode 等
RSS 和 VSS 的差异不在数值大小，而在统计维度：VSS 是虚拟地址空间的“地图尺寸”，RSS 是当前“已铺砖的地面面积”。想定位真实内存压力，盯 RSS；想排查地址空间爆炸（比如内存泄漏早期只 malloc 不写），VSS 才是第一个报警信号。
