Memory: VSS/RSS/PSS/USS

Source: Internet
Author: User

From: http://netcome.javaeye.com/blog/746793

 

Terms
VSS-virtual set size virtual memory consumption (including memory occupied by shared libraries)
RSS-resident set size actually uses physical memory (including memory occupied by shared libraries)
Pss-proportional set size physical memory actually used (proportional allocation of memory occupied by the Shared Library)
USS-unique set size physical memory occupied by the process (excluding the memory occupied by the Shared Library)
Generally, the memory usage is as follows: VSS> = RSS> = PSS> = USS

Overview

The aim of this post is to provide information that will assist in interpreting Memory reports from varous tools so the true memory usage for Linux processes and the system can be determined.

Android has a tool called procrank (/system/xbin/procrank), which lists out the memory usage of Linux processes in order from highest to lowest usage. the sizes reported per process are VSS, RSS, PSS, and USS.

For the sake of simplicity in this description, memory will be expressed in terms of pages, rather than bytes. Linux systems like ours manage memory in 4096 byte pages at the lowest level.

VSS (reported as vsz from PS) is the total accessible address space of a process. this size also includes memory that may not be resident in Ram like mallocs that have been allocated but not written. VSS is of very little use for determing real memory usage of a process.

RSS is the total memory actually held in RAM for a process. RSS can be misleading, because it reports the total all of the shared libraries that the process uses, even though a shared library is only loaded into memory once regardless of how many processes use it. RSS is not an accurate representation of the memory usage for a single process.

Pss differs from RSS in that it reports the proportional size of its shared libraries, I. e. if three processes all use a shared library that has 30 pages, that library will only contribute 10 pages to the PSS that is reported for each of the three processes. PSS is a very useful number because when the PSS for all processes in the system are summed together, that is a good representation for the total memory usage in the system. when a process is killed, the shared libraries that contributed to its PSS will be proportionally distributed to the PSS totals for the remaining processes still using that library. in this way PSS can be slightly misleading, because when a process is killed, PSS does not accurately represent the memory returned to the overall system.

USS is the total private memory for a process, I. e. that memory that is completely unique to that process. USS is an extremely useful number because it indicates the true incremental cost of running a special process. when a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.

For systems that have Python available, there is also a nice tool called smem that will report memory statistics including all of these categories.

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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.