Я прочитал объяснение по поводу VSS/RSS/PSS/USS:
Цель этой публикации - предоставить информацию, которая поможет интерпретировать отчеты о памяти из различных инструментов, чтобы можно было определить истинное использование памяти для процессов Linux и системы.
В Android есть инструмент под названием procrank (/system/xbin/procrank), в котором перечислены возможности использования Linux-процессов в памяти от наивысшего до самого низкого уровня использования. Размеры, указанные для каждого процесса, - это VSS, RSS, PSS и USS.
Для простоты в этом описании память будет выражаться через страницы, а не байты. Linux-системы, такие как наши, управляют памятью на 4096 байтовых страницах на самом низком уровне.
VSS (как VSZ от ps) - это общее доступное адресное пространство процесса. Этот размер также включает в себя память, которая не может быть резидентной в ОЗУ, как mallocs, которые были выделены, но не были записаны. VSS очень мало используется для определения реального использования памяти в процессе.
RSS - это общая память, фактически хранящаяся в ОЗУ для процесса. RSS может вводить в заблуждение, поскольку он сообщает общее количество всех разделяемых библиотек, которые использует этот процесс, даже если разделяемая библиотека загружается только в память один раз независимо от того, сколько процессов использует ее. RSS не является точным представлением использования памяти для одного процесса.
PSS отличается от RSS тем, что он сообщает о пропорциональном размере своих общих библиотек, т.е. если три процесса используют общую библиотеку, которая имеет 30 страниц, эта библиотека будет вносить только 10 страниц в PSS, который сообщается для каждого из три процесса. 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
#
Но я не могу найти оригинал этой статьи, и я хотел бы знать, является ли это объяснение точным.
