vsz是进程申请的虚拟内存总量（含未映射部分），rss是其当前驻留物理内存的实际大小；vsz≠真实内存占用，rss才反映实际ram消耗且为oom killer判定依据。
看进程内存，别只盯着 ps aux 里那一串数字——VSZ 和 RSS 差得不是一点半点，直接拿 VSZ 判断“哪个进程吃内存”，大概率会误判。
ps aux 输出中 VSZ 和 RSS 到底代表什么
VSZ（Virtual Memory Size）是进程申请的全部虚拟地址空间大小，单位 KB。它包括：已 malloc 但没写过的堆内存、mmap 映射的文件或共享库、未加载的代码段、甚至预留但完全没碰过的地址区间。这些都不消耗物理内存，只是“画了个圈”。RSS（Resident Set Size）才是当前真正在物理 RAM 里驻留的部分，比如已写入的堆页、正在执行的代码页、栈上活跃数据等。
常见误解是认为 VSZ 大 = 内存压力大。错。Java 进程启动时 VSZ 动辄 2GB+，RSS 可能才 100MB；一个只 malloc 不 memset 的 C 程序，VSZ 能到 500MB，RSS 却只有几 MB。
怎么快速定位真正吃物理内存的进程
用 ps 按 RSS 降序查最有效：
ps aux --sort -rss | head -n 10
注意三点：
-
--sort -rss中的负号表示降序，不加就是升序，容易看反 -
ps默认显示的是 KB，数值大不代表实际压力大，要结合系统总内存看比例（%MEM列更直观） - 有些进程
RSS高但合理，比如数据库缓存、视频转码进程；要结合业务判断是否异常
为什么 RSS 比 VSZ 更值得监控
因为内存不足时，内核杀进程（OOM Killer）依据的是 RSS，不是 VSZ。系统物理内存快耗尽时，RSS 总和接近 /proc/meminfo 中的 MemTotal 才真正危险。而 VSZ 总和可以轻松超过物理内存数倍——Linux 的虚拟内存设计本就允许这样。
另外：RSS 包含共享库占用的物理页，所以多个进程共用 glibc 时，这部分内存会被重复计入各自 RSS，导致总 RSS > 实际物理占用。若需更精确评估单个进程独占内存，得看 USS（Unique Set Size），要用 smem 工具：
smem -p -c "pid uss rss pss cmdline" | head -n 10
容易被忽略的细节：RSS 并不等于“该进程专属的物理内存”
RSS 是“驻留集”，但它不区分独占还是共享。例如两个 Python 进程都 import numpy，底层共享的 NumPy so 库物理页会算进双方 RSS。所以：
- 用
ps aux看单个进程，RSS偏高是正常的 - 用
free看全局，used接近MemTotal才说明物理内存紧张 - 想确认某个进程是否真的在膨胀，应持续观察其
RSS是否随时间线性增长，而非某次快照值
真正难判断的，是那些 RSS 缓慢爬升、又偶尔回落的进程——可能是内存泄漏，也可能是应用自身的缓存策略。这时候得配合 /proc/<pid>/statm</pid> 或 pmap -x <pid></pid> 看具体内存段分布，不能只信 ps 一行数字。
