直接盯vmrss或rss，因其反映进程当前驻留物理内存（单位kb），而vmsize/vsz仅为虚拟地址空间总和，含大量未映射页，不能体现真实ram压力。
看进程实际吃了多少物理内存，直接盯 VmRSS 或 RSS（等价于 RES），别信 VmSize 或 VSZ——后者只是画了个内存圈，连一页物理 RAM 都不一定占。
怎么快速查某个进程的 RSS（真实物理内存）
最稳、无解析误差的方式是读内核原始数据：
- 用
cat /proc/<code>PID/status | grep VmRSS，输出如VmRSS: 245672 kB，这就是当前驻留 RAM 的准确值（单位 KB） - 临时排查更常用
ps -o pid,rss,comm -p <code>PID，RSS列数值和VmRSS基本一致（差值通常 ≤ 4 KB） - 避免用
ps aux默认字段——它不显示RSS，且%MEM是百分比，小内存机器上容易误判
为什么 VSZ 和 VmSize 完全不能反映物理压力
VSZ（或 VmSize）是虚拟地址空间总和，包含大量“没动过”的内存：
- malloc 了但没写入的堆页：内核只分配虚拟地址，物理页按需分配（lazy allocation）
- mmap 映射的大文件（如数据库索引）：仅加载访问过的页，其余仍算进 VSZ
- 共享库代码段：libc 等被上百个进程共用，VSZ 把每份都加一遍，但物理页只存一份
- Java 进程启动后 VSZ 动辄 3–4 GB，RSS 可能才 150 MB；拿 VSZ 排序找“吃内存大户”，90% 会错杀
top/htop 中 RES 和 RSS 不一致？这不是 bug
同一时刻运行 ps -o rss -p <code>PID 和 top -b -n1 -p <code>PID | grep PID，数值可能差几 MB。原因很实在：
-
ps的RSS严格统计用户态已分配、未换出的物理页 -
top的RES会额外计入部分 page cache 中刚被该进程访问过的文件映射页（哪怕内容来自磁盘） - 这种差异在跑日志写入、大文件解压、数据库查询的进程上最明显——它们频繁触碰文件页，
top就显得“更慷慨” - 监控脚本必须用
/proc/<code>PID/statm 第二列（awk '{print $2 * 4}' /proc/<code>PID/statm）或VmRSS，否则自动告警可能误抖
真正要警惕的不是 RSS 大小，而是它的变化模式
单次 RSS 高不等于有问题，比如 Java 应用 Full GC 前 RSS 冲到 1.2 GB 很正常。但以下信号值得立刻介入：
-
VmRSS持续缓慢上涨（例如每小时 +30–50 MB），且VmHWM（历史最高值）同步爬升，说明内存长期持有未释放 - 用
watch -n 5 'grep -E "VmRSS|VmHWM" /proc/<code>PID/status' 观察 10 分钟，若 RSS 不回落、HWM 不降，基本可判定泄漏 - 容器环境别只看
VmRSS：cgroup v1 下/sys/fs/cgroup/memory/xxx/memory.usage_in_bytes才是容器级真实用量，VmRSS只反映进程视角 - 注意：
VmRSS不含 page cache、slab、dentry 等内核内存——这些在/proc/meminfo单独分类，别混为一谈
