vmrss是进程当前占用的物理内存大小，单位kb，不包含swap页和未映射内存，最贴近真实ram使用情况。
直接看 VmRSS，它就是进程当前占用的物理内存大小
Linux 中判断一个进程“实际吃了多少物理内存”，VmRSS 是最贴近真实情况的指标。它出现在 /proc/[pid]/status 文件里，单位是 KB，值越大说明该进程在 RAM 中驻留的页越多。注意：它不包含已被 swap 出去的页，也不含未映射的虚拟内存（比如 malloc 了但没 touch 的内存），所以比 VmSize 或 VSZ 更可信。
cat /proc/[pid]/status | grep VmRSS 是最快捷的查看方式
假设你想查 PID 为 1234 的进程：
cat /proc/1234/status | grep VmRSS
输出类似：VmRSS: 184520 kB。这个数字就是它当前占用了约 180 MB 物理内存。
常见误操作：
- 用
ps aux看RSS列——它和VmRSS基本等价，但精度略低（ps 会四舍五入到 KB，且受内核采样时机影响） - 把
VSZ当成真实内存——它对应VmSize，是虚拟地址空间总和，可能含大量 mmap 区域或预留未用内存，完全不能反映物理压力 - 依赖
%MEM排序找大头——它基于 RSS / 总物理内存计算，但小内存机器上百分比容易失真，优先看绝对值RSS或VmRSS
VmRSS 和 RES、RSS 的关系不是 1:1，但生产环境可视为等效
在 top 或 ps 输出中看到的 RES（ps 中叫 RSS）字段，底层基本就是从 /proc/[pid]/statm 的第 2 列（即 RSS 页面数）换算而来，而 /proc/[pid]/statm 的 RSS 又和 /proc/[pid]/status 中的 VmRSS 数值高度一致（差值通常 ≤ 4 KB）。所以：
- 监控脚本建议直接读
/proc/[pid]/status，稳定、无解析开销 - 临时排查用
ps aux --sort=-rss | head -5完全够用 - 不要试图用
VmData + VmStk + VmExe加总来逼近VmRSS——共享库、匿名映射、内存映射文件等都会让加法失效
真正要警惕的是 VmRSS 持续缓慢上涨，而非单次峰值
一个 Java 进程启动后 VmRSS 从 200 MB 涨到 800 MB 是正常的；但如果每小时稳定+50 MB，且 GC 日志显示老年代持续增长，那大概率是泄漏。此时：
- 别只看
VmRSS绝对值，用watch -n 5 'cat /proc/1234/status | grep VmRSS'观察变化趋势 -
VmHWM（High Water Mark）也值得留意——它记录该进程至今达到过的最高VmRSS，如果VmRSS回落但VmHWM不降，说明内存曾被大量分配并长期持有 - 注意容器环境：cgroup v1 下
/sys/fs/cgroup/memory/xxx/memory.usage_in_bytes才是容器级真实用量，VmRSS只反映进程视角
最易被忽略的一点：VmRSS 不统计 page cache、slab、dentry 等内核内存——它们在 /proc/meminfo 里单独分类。如果你发现 free -h 显示可用内存极低，但所有进程的 VmRSS 加起来远小于总量，问题大概率出在内核缓存或驱动层，而不是用户进程。
