我讀了解釋有關VSS/RSS/PSS/USS：這個關於VSS/RSS/PSS/USS的解釋是否準確？
這篇文章的目的是提供將有助於解釋從各種工具存儲報告信息，從而真正的內存使用Linux進程和系統可以確定。
Android有一個名爲procrank（/ system/xbin/procrank）的工具，它按從高到低的順序列出了Linux進程的內存使用情況。每個進程報告的大小是VSS，RSS，PSS和USS。
爲了簡化描述，存儲器將用頁面而不是字節表示。像我們這樣的Linux系統以最低級別的4096字節頁面管理內存。
VSS（以psz的VSZ形式報告）是進程的總可訪問地址空間。這個大小還包括可能不駐留在RAM中的內存，例如已分配但未寫入的malloc。 VSS對於確定進程的實際內存使用情況的用處甚少。
RSS是一個進程實際保存在RAM中的總內存。 RSS可能會引起誤解，因爲它會報告進程使用的所有共享庫的總數，即使共享庫只是一次加載到內存中，而不管有多少進程使用它。 RSS不是單個進程的內存使用情況的準確表示。
PSS與RSS的不同之處在於它報告了其共享庫的比例大小，即如果三個進程都使用共有30個頁面的共享庫，那麼該庫僅向每個報告的PSS貢獻10個頁面這三個過程。 PSS是一個非常有用的數字，因爲當系統中所有進程的PSS相加在一起時，這是系統中總內存使用情況的良好表示。當進程被終止時，貢獻給其PSS的共享庫將按比例分配給仍然使用該庫的其餘進程的PSS總計。通過這種方式，PSS可能會有些誤導，因爲當進程被終止時，PSS不能準確地表示返回到整個系統的內存。
USS是一個進程的總私有內存，即該進程完全獨一無二的內存。 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
#
但我找不到這篇文章的原創，我想知道這樣的解釋是否準確。
我很好奇......你在哪裏複製/粘貼此信息？ – Skeets