Linux怎么查看进程消耗的VSS/RSS/PSS内存 Linux内存指标详解

Linux怎么查看进程消耗的VSS/RSS/PSS内存 Linux内存指标详解

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

ps 命令只能看到 VSZ 和 RSS，看不到 PSS/USS

说到排查内存问题，很多工程师的第一反应就是敲下 ps aux --sort -rss。这个命令确实能给出一个排序，但这里头其实有个关键限制：你看到的 VSZ 其实就是 VSS（单位是KB），而 RSS 就是驻留集大小。至于更关键的 PSS 和 USS，ps 命令本身是给不出来的。为什么呢？因为这两个值需要去解析 /proc/[pid]/smaps 这个文件，并根据共享比例进行计算或统计独占部分，内核并没有直接把它们暴露给 ps 命令的字段。

这里有个常见的误区，以为 %MEM 这个百分比能真实反映进程的内存压力。其实不然，它仅仅是 RSS / MemTotal 的结果。问题在于，RSS 会把像 libc、libpython 这样的共享库，在每个使用它的进程里都重复计算一遍。这就导致你看到的 RSS 总量，可能远远高于系统实际被占用的物理内存。

• VSZ 包含了所有已经通过 mmap 映射但还没真正访问（触发缺页中断）的内存区域，比如你 malloc 了一大块空间但还没往里写数据。
• RSS 也并不完全等于“当前吃掉的物理内存”，它里面混着共享页，而且不区分这些内存是否可以被回收（比如映射的 page cache）。
• 所以，如果你想定位那个真正拖垮系统的“元凶”，只看 RSS 很容易误判。举个典型的例子：20个 Ja va 进程都共用同一个 JDK 的共享库，它们的 RSS 总和可能比实际占用的物理内存高出 3 到 5 倍。

smem 是唯一能直接输出 PSS/USS 的常用命令行工具

那么，有没有更直接的工具呢？有，就是 smem。这个工具的设计目的就是干这个的。它会去读取每个进程对应的 /proc/[pid]/smaps 文件，按照内存页的粒度进行统计和聚合，自动帮你算出 PSS（共享内存均摊后的结果）和 USS（完全私有的内存）。安装之后，基本的使用命令如下：

$ sudo smem -k -c "pid user command pss uss rss"

这里有几个关键参数值得一说：

• -k：让输出以 KB 为单位，看起来更直观（默认是字节，数字会很长）。
• -c：用来自定义显示的列，你必须显式指定 pss 和 uss，它们才会出现在结果里。
• 你还可以加上 -P "nginx" 来过滤进程名，用 -u 按用户汇总，或者用 -w 查看系统级别的内存总览。

需要注意一点：smem 通常需要 root 权限才能读取所有进程的 smaps 文件。如果是非 root 用户运行，你只能看到自己权限下进程的 USS/PSS，而且部分字段可能会是空的。

手动从 /proc/[pid]/smaps 提取 PSS/USS 要小心字段歧义

当然，如果你喜欢刨根问底，也可以直接去啃 /proc/[pid]/smaps 这个原始文件。不过，这个文件内容可不少，每个进程都有几十行统计信息，真正对我们有用的其实就几行：

• 找到以 Pss: 开头的行，后面的数值就是该虚拟内存区域（VMA）对进程总 PSS 的贡献值（单位KB），把整个文件里所有的 Pss: 值加起来，就是这个进程的 PSS。
• USS 在这个文件里没有直接的汇总字段。理论上，你需要把所有 MMUPageSize: 为 4kB 且是私有（Private）的页大小加起来。更简单一点的理解是：USS ≈ 所有区域的 Size: 减去共享的部分。但实际操作起来挺麻烦的，所以通常的建议是：直接用 smem。
• 另外，千万别把 Referenced: 和 Rss: 搞混了。Referenced 表示最近被访问过的物理页，而 Rss 表示当前被映射的所有物理页（包括那些还没被访问过的）。

手动计算时一个典型的错误是：用 grep "Pss:" 抓取行，然后用 awk 求和。这可能会漏掉一些特殊的 VMA（比如 vvar、vdso），因为它们可能没有 Pss: 这一行——而 smem 在内部已经做好了这些边缘情况的遍历和回退处理。

USS 才是 kill 进程后能立刻释放的内存

理解这几个指标的现实意义是什么？最关键的一点在于：当系统内存不足（OOM）触发 killer 机制时，内核会优先选择 USS 大、但 PSS 小的进程来干掉。原因很直接：USS 大，意味着这个进程独占了大量的物理内存，杀掉它，这些内存立刻就能被释放出来，收益最高。反过来，如果一个进程 RSS 很高但 USS 很小（比如一堆通过 fork 产生的 Python worker，共享同一个解释器），那么杀掉其中一个，对释放物理内存几乎没什么帮助。

怎么验证呢？可以试试这个方法：

• 先找到一个疑似内存泄漏的进程，记下它的 PID。
• 执行 cat /proc/[pid]/smaps | awk '/^USS:/ {sum+=$2} END {print sum}' 来估算 USS（注意：较新的内核版本才有直接的 USS: 字段；老内核还得靠 smem 或手动计算）。
• 同时，用 cat /proc/[pid]/statm | awk '{print $1 * 4}' 快速估算一下它的 RSS（单位KB）。如果算出来的 USS 只有 RSS 的 10%–20%，那基本可以断定，这个进程严重依赖共享内存，它很可能不是导致内存紧张的首要原因。

真正棘手的情况，是 USS 在缓慢上涨，但 PSS 却变化不明显。这通常指向堆内存泄漏或者没有正确释放的 mmap 区域。遇到这种情况，就需要祭出更深入的工具了，比如 pmap -x [pid] 或者 gdb --pid [pid] 来进一步分析内存布局了。