Android内存之VSS/RSS/PSS/USS

Terms

  • VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)
  • RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存)
  • PSS - Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
  • USS - Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)

一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS

Overview

The aim of this post is to provide information that will assist in interpreting memory reports from various 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 to. 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 particular 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 
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
#

 原文地址 http://hi.baidu.com/donghaozheng/blog/item/235da701ab70f60a1c95832e.html
时间: 2024-12-30 04:19:33

Android内存之VSS/RSS/PSS/USS的相关文章

内存VSS/RSS/PSS/USS名词解释

VSS(virtual set size)虚拟耗用内存(包含共享库占用的内存) RSS(Resident set size)实际使用物理内存(包含共享库占用的内存) RSS是进程实际驻存在物理内存的部分的大小.因为一个进程执行不需要把整个进程都全部驻存到物理内存.RSS是最常用的内存指标,表示进程占用的物理内存大小.但是,将各进程的RSS值相加,通常会超出整个系统的内存消耗,这是因为RSS中每个进程都包含了各进程间共享的内存,因此存在重叠部分. VSS是一个进程的总的大小.只有当进程执行且整个进

Linux内存VSS,RSS,PSS,USS解析

转载:http://myeyeofjava.iteye.com/blog/1837860 adb shell procrank | grep com.package > appmem说明:五个参数分别为PID Vss Rss Pss Uss 一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)RSS - Resident Set Size 实际使用物理内存(包含共享库占用

android内存耗用:VSS/RSS/PSS/USS

VSS- Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)  不是真实当前应用进程所占用的内存. 内存分配的原理 从操作系统角度来看,进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存). 1.brk是将数据段(.data)的最高地址指针_edata往高地址推: 2.mmap是在进程的虚拟地址空间中(堆和栈中间,称为文件映射区域的地方)找一块空闲的虚拟内存.      这两种方式分配的都是虚拟内存,没有分配物理内存.在第一次访问已分配的虚拟地址

linux--VSS/RSS/PSS/USS

|--内存耗用:VSS/RSS/PSS/USS VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存) RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存) PSS - Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存) USS - Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存) 一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >=

Android内存等信息

1. Linux中proc目录下文件详解 http://wenku.baidu.com/view/2ce89f00a6c30c2259019ef1.html 2. Android系统/proc目录详解 3. android proc 进程信息解析 http://wenku.baidu.com/view/6530ad58312b3169a451a4eb.html?re=view 4. How to get memory usage at run time in c++? 5. 使用getrusag

Android内存和Cpu性能测试

Android内存限制java虚拟机有内存使用上限的限制 adb shell进入手机,这此参数被纪录在/system/build.prop中,如果想直接查看可以使用adb shell getprop 单个应用程序最大内存限制,超过这个值会产生OOMdalvik.vm.heapgrowthlimit 应用启动后分配的初始内存dalvik.vm.heapstartsize 单个java虚拟机最大的内存限制,超过这个值会产生OOMdalvik.vm.heapsize 小米2S的一些内存限制 #查看单个

android内存优化大全_上

转载请注明本文出自大苞米的博客(http://blog.csdn.net/a396901990),谢谢支持! 写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参考的文章). 内存简介: RAM(random acc

ANDROID内存优化以及原理(大汇总——上)

写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参考的文章). 内存简介: RAM(random access memory)随机存取存储器.说白了就是内存. 一般Java在内存分配时会涉及到以下区域: 寄存器(R

ANDROID内存优化——大汇总(转)

原文作者博客:转载请注明本文出自大苞米的博客(http://blog.csdn.net/a396901990),谢谢支持! ANDROID内存优化(大汇总——上) 写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参