rss才是真实物理内存占用，单位kb，反映进程当前驻留ram的页数，不包含swap和未映射虚拟页；ps aux --sort=-%mem按占比排序易误判，应优先用ps -eo pid,comm,%mem,rss --sort=-rss看绝对值，或直接读/proc/pid/status中vmrss字段。
ps aux --sort=-%mem 能快速定位高内存进程，但 RSS 值才是真实物理内存占用
很多人用 ps aux 看到的 %MEM 是百分比，容易误判；真正反映进程吃掉多少 RAM 的是 RSS（Resident Set Size），单位是 KB。它不包含 swap、不包含未实际加载的虚拟页，只算当前驻留在物理内存里的部分。
-
ps aux --sort=-%mem | head -n 10：按内存占比倒序，适合一眼找出“最耗内存比例”的几个进程 -
ps -eo pid,comm,%mem,rss --sort=-rss | head -n 10：按实际 KB 数倒序，更贴近真实压力来源 - 注意：
RSS不等于进程总开销——共享库（如 libc）会被多个进程共用，RSS会重复统计，所以所有进程 RSS 加起来可能远超物理内存总量
/proc//status 里 VmRSS 是最准的单进程物理内存快照
当你已经知道某个 PID（比如通过 ps 或 top 找到），直接读 /proc/<pid>/status</pid> 比任何命令都可靠，因为它是内核实时维护的原始数据。
-
grep VmRSS /proc/1234/status输出类似VmRSS: 184528 kB，这就是该进程此刻真实占用的物理内存 - 别用
VmSize（即 VIRT）判断内存压力——它包含 mmap 的文件、未分配的堆预留空间、甚至已 swap out 的页，数值常虚高数倍 - 如果
VmRSS长期 > 1GB 且持续增长，基本可判定该进程存在内存泄漏或缓存失控
pmap -x 能看出内存分布，但 RSS 总和要自己加
pmap 不直接给总 RSS，但它把每一块内存段（堆、栈、共享库、anon mapping）拆开列出来，适合排查“为什么 RSS 这么大”。
-
pmap -x 1234输出末尾有一行mapped: XXXK writeable/private: YYYK shared: ZZZK，其中writeable/private接近该进程独占的 RSS 主体 - 最后一行的
rss列数字加起来，才等于/proc/<pid>/status</pid>中的VmRSS—— 但pmap默认不显示这行，得加-x才有 - 常见陷阱：看到某段
anon占几百 MB 就以为是 bug，其实可能是 JVM 的 heap 或 Python 的array.array分配，得结合语言运行时看
top 和 htop 适合实时盯梢，但默认字段容易误导
top 按 Shift+M 排序后，关键要看 RES 列（等价于 RSS），不是 VIRT 或 %MEM；htop 更友好，但默认不显示 RES，需手动开启。
-
top启动后按f→ 选中RES→ 按Space启用，再按Shift+M，才能真正按物理内存排序 -
htop启动后按F2→ “Columns” → 把RES加入显示列表，否则你看到的只是估算值 - 注意：
top的RES单位是 KB，但默认不带逗号，123456 容易被当成 123KB，其实是 123MB —— 看错单位是高频失误
MemAvailable 是否持续低于 5% 总内存，以及有没有进程因缺内存被 OOM killer 杀掉——这些信号比任何单条命令都关键。
