ps命令中VSZ和RSS的单位均为KB；VSZ表示进程虚拟内存大小（即VSS），RSS表示进程实际驻留物理内存大小（即常驻集大小），二者均以KB为单位，非字节亦非MB。
ps 命令直接看 VSZ 和 RSS，单位是 KB
VSZ 就是 VSS（Virtual Set Size），RSS 就是 Resident Set Size——ps 不叫它们 VSS/RSS，但字段名和含义完全对应。ps 输出里 VSZ 列就是 VSS，RSS 列就是 RSS，单位统一为 KB，不是字节也不是 MB。
常用命令示例：
-
ps -p 1234 -o pid,vsz,rss,comm：查指定 PID 的 VSS/RSS -
ps aux --sort=-rss | head -n 5：按 RSS 降序排，取前 5 个最吃物理内存的进程 -
ps aux --sort=-vsz | head -n 5：按 VSS（即 VSZ）降序排，注意这容易误判“真内存压力”
别用 ps aux 默认输出——它不显示 VSZ 和 RSS，默认的 VIRT 和 RES 是同义字段（VIRT ≡ VSZ，RES ≡ RSS），但列名不一致容易混淆。明确用 -o 指定字段，避免歧义。
/proc/PID/status 里的 VmSize 和 VmRSS 最准，单位也是 KB
内核原始数据源，没经过格式化或舍入，数值比 ps 更稳。尤其当你要写监控脚本、做告警阈值判断时，必须用这个。
执行：grep -E 'VmSize|VmRSS' /proc/1234/status，输出类似：
VmSize: 123456 kB VmRSS: 45678 kB
注意两点：
-
VmSize对应 VSS，VmRSS对应 RSS，单位都是 KB - 如果进程已退出，
/proc/1234/目录消失，读不到；ps还能返回历史快照，但不准
别用 /proc/PID/statm 算 RSS：第二列 × 4 是近似值（页大小假设为 4KB），但某些系统启用大页（huge page）时会偏差，VmRSS 才是权威。
top 和 htop 显示 RES/VIRT，但单位和逻辑有坑
top 里 RES = RSS，VIRT = VSS，单位 KB；htop 里 RES 也是 RSS，但默认不标单位，MEM% 列可能恒为 0（某些发行版编译时没开 MEMORY_PERCENTAGE 支持）。
实操要点：
-
top启动后按 Shift + M 可按 RES 排序，但数值是采样瞬时值，和ps可能差几 MB——top的 RES 会额外计入部分刚被该进程访问过的 page cache 页，ps更严格只计用户态驻留页 -
htop按F2→ Columns → 确保RES字段启用，并心里记住它是 KB；它不显示 VSS 的占比，也没法按 VSS 排序 - 别信
htop的MEM%：若为 0，只能靠RES数值自己除以free -h中的MemTotal
为什么不能拿 VSZ/VSS 当内存压力指标
VSS 是“画圈”，RSS 才是“占坑”。一个 Java 进程 VSZ=3200000（约 3.2GB），RSS=180000（180MB）很常见——那多出来的 3GB 多数是 mmap 预留、未 touch 的堆页、共享库虚拟映射，根本没占物理内存。
OOM Killer 杀进程只看 RSS，不是 VSZ；free -h 的 available 接近 0 时，真正该盯的是所有进程 RSS 总和是否逼近 /proc/meminfo 中的 MemTotal。
最容易踩的坑是：用 ps aux --sort=-vsz 找“内存大户”，结果 kill 掉一个 VSZ 很大但 RSS 很小的进程，系统内存压力毫无缓解——因为那块虚拟地址压根没落地。
