android - 这个关于 VSS/RSS/PSS/USS 的解释准确吗？

Question

我阅读了关于 VSS/RSS/PSS/USS 的说明:

---

本文的目的是提供有助于解释各种工具的内存报告的信息，以便确定 Linux 进程和系统的真实内存使用情况。

Android 有一个名为 procrank (/system/xbin/procrank) 的工具，它按使用率从高到低的顺序列出了 Linux 进程的内存使用情况。每个进程报告的大小是 VSS、RSS、PSS 和 USS。

为了描述的简单起见，内存将用页而不是字节来表示。像我们这样的 Linux 系统在最低级别管理 4096 字节页面中的内存。

VSS(从 ps 报告为 VSZ)是进程的总可访问地址空间。此大小还包括可能不驻留在 RAM 中的内存，例如已分配但未写入的 malloc。 VSS 对于确定进程的实际内存使用情况几乎没有用处。

RSS 是进程在 RAM 中实际保存的总内存。 RSS 可能会产生误导，因为它报告了进程使用的所有共享库的总数，即使共享库只加载到内存中一次，而不管有多少进程使用它。 RSS 不能准确表示单个进程的内存使用情况。

PSS 与 RSS 的不同之处在于它报告其共享库的比例大小，即如果三个进程都使用一个有 30 页的共享库，则该库将只为每个报告的 PSS 贡献 10 页三个过程。 PSS 是一个非常有用的数字，因为当系统中所有进程的 PSS 加在一起时，它可以很好地表示系统中的总内存使用量。当一个进程被杀死时，为其 PSS 做出贡献的共享库将按比例分配到仍在使用该库的剩余进程的 PSS 总数中。这样 PSS 可能会有点误导，因为当一个进程被杀死时，PSS 并不能准确地表示返回给整个系统的内存。

USS 是进程的总私有(private)内存，即该进程完全独特的内存。 USS 是一个非常有用的数字，因为它表示运行特定进程的真正增量成本。当一个进程被杀死时，USS 是实际返回给系统的总内存。当最初怀疑进程中存在内存泄漏时，USS 是最好的观察值。

对于有 Python 可用的系统，还有一个名为 smem 的好工具，它可以报告包括所有这些类别的内存统计信息。

# procrank
procrank
PID      Vss        Rss           Pss         Uss   cmdline
481   31536K   30936K   14337K    9956K  system_server
475   26128K   26128K   10046K    5992K  zygote
526   25108K   25108K    9225K    5384K  android.process.acore
523   22388K   22388K    7166K    3432K  com.android.phone
574   21632K   21632K    6109K    2468K  com.android.settings
521   20816K   20816K    6050K    2776K  jp.co.omronsoft.openwnn
474    3304K    3304K    1097K     624K   /system/bin/mediaserver
37     304K      304K     289K      288K  /sbin/adbd
29     720K      720K     261K      212K  /system/bin/rild
601     412K     412K     225K      216K  procrank
   1     204K     204K     185K      184K  /init
35     388K     388K     182K      172K  /system/bin/qemud
284     384K     384K     160K      148K  top
27     376K     376K     148K      136K  /system/bin/vold
261     332K     332K     123K     112K  logcat
33     396K     396K     105K       80K   /system/bin/keystore
32     316K     316K     100K       88K   /system/bin/installd
269     328K     328K      95K       72K  /system/bin/sh
26     280K     280K      93K       84K   /system/bin/servicemanager
45     304K     304K      91K       80K   /system/bin/qemu-props
34     324K     324K      91K       68K   /system/bin/sh
260     324K     324K      91K       68K   /system/bin/sh
600     324K     324K      91K      68K   /system/bin/sh
25     308K     308K      88K       68K   /system/bin/sh
28     232K     232K      67K       60K   /system/bin/debuggerd
#

---

但是我找不到这篇文章的原文，我想知道这个解释是否准确。

Answer 1

这听起来很正确，也符合此处的描述:http://elinux.org/Android_Memory_Usage

从页面...

• Vss = 虚拟集大小
• Rss = 驻留集大小
• Pss = 比例集大小
• Uss = 唯一集大小