Memory: VSS/RSS/PSS/USS

本文提供了解释Linux进程内存报告中VSS、RSS、PSS和USS的概念及其计算方式,帮助理解真实内存使用情况。Android的procrank工具展示了这些指标,用于系统级和单进程内存分析。

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

 

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

<think>嗯,用户这次想了解shmem、RSSPSS这三个内存指标的具体含义和区别。从用户引用的大量资料来看,ta应该是在做Linux系统级的内存分析,可能是运维或者开发人员。用户特意提到“不是真正的需求”,说明这些引用只是背景材料,核心需求还是概念澄清。 用户引用的材料挺专业的,其中引用[4]的总结很清晰:VSS是虚拟内存,RSS是实际物理内存,PSS是比例分配的共享内存,USS是独占内存。不过关于shmem的信息比较零散,需要我补充完整。 首先得明确shmem(共享内存)属于IPC机制,通过tmpfs实现。而RSS作为最基础的内存指标,它包含了进程所有占用的物理页,包括独占和共享部分。但RSS的最大问题就是重复计算共享内存,比如五个进程共用同一个50MB的共享库,RSS会把这50MB算在每个进程头上,总和就变成250MB了——显然不合理。 PSS就是为解决这个问题而生的,它把共享内存按引用进程数均摊。比如两个进程共享100MB内存,每个进程的PSS就只计50MB。USS则更纯粹,只算进程私有的非共享内存,这对排查内存泄漏特别有用。 用户没问但可能关心的点:smaps文件里能查到详细的内存构成,而Android系统常用的内存分析工具dumpsys meminfo就是基于PSS的。不过用户当前问题集中在概念层面,这些实现细节暂时不用展开。 最后要注意对比维度:shmem是内存类型(共享内存块),而RSS/PSS/USS是统计方式。就像比较“苹果”和“水果重量测量方法”属于不同范畴。这个维度差异需要在回答里明确区分,否则容易造成混淆。 </think>以下是关于 **shmem**、**RSS**、**PSS** 的详细解释及对比: --- ### **1. 核心概念** #### **shmem (Shared Memory)** - **含义**:进程间共享的内存区域,通过 `tmpfs` 或 `shmget()` 系统调用分配,允许多个进程访问同一块物理内存。 - **作用**:减少重复数据拷贝,提升进程间通信效率(如数据库、图形渲染)。 - **特点**: - 物理内存仅存一份副本,多进程通过虚拟地址映射访问。 - 在 `smaps` 文件中标记为 `Shared_*`(如 `Shared_Clean`/`Shared_Dirty`)。 #### **RSS (Resident Set Size)** - **含义**:进程**实际占用物理内存的总量**(含私有内存和共享内存)。 - **计算公式**: ```math \text{RSS} = \text{Private\_Clean} + \text{Private\_Dirty} + \text{Shared\_Clean} + \text{Shared\_Dirty} ``` - **缺点**: - 重复计算共享内存(如 10 个进程共享 100MB 库,RSS 总计 1000MB)。 - 无法反映真实物理内存占用[^3]。 #### **PSS (Proportional Set Size)** - **含义**:按比例分配的物理内存,**共享内存均摊给使用它的进程**。 - **计算公式**: ```math \text{PSS} = \text{Private} + \frac{\text{Shared}}{\text{共享进程数}} ``` - **作用**: - 更准确评估系统总内存占用(所有进程 PSS 之和 ≈ 实际物理内存使用)。 - Android/Linux 内存优化中常用指标[^1][^4]。 --- ### **2. 三者的区别** | **指标** | **计算范围** | **共享内存处理方式** | **适用场景** | |----------|----------------------------|----------------------------|----------------------------------| | **shmem**| 进程间共享的物理内存块 | 内存本身,非统计指标 | 进程间高效通信 | | **RSS** | 进程总物理内存(含共享) | **重复计算**共享部分 | 粗略查看进程内存占用 | | **PSS** | 进程实际分摊的物理内存 | **按比例分配**共享部分 | 系统总内存分析、优化评估[^1][^4] | --- ### **3. 典型示例** 假设两个进程共享 100MB 的 `libc.so`: - **RSS 报告**: - 进程 A:私有内存 50MB + 共享库 100MB → **150MB** - 进程 B:私有内存 50MB + 共享库 100MB → **150MB** - **总和 300MB**(实际物理内存仅 200MB)。 - **PSS 报告**: - 进程 A:50MB + (100MB / 2) = **100MB** - 进程 B:50MB + (100MB / 2) = **100MB** - **总和 200MB**(符合物理内存真实占用)[^1][^4]。 --- ### **4. 关键结论** - **排查内存泄漏**:优先看 **USS**(进程独占内存,不含共享部分)。 - **系统总内存分析**:用 **PSS** 避免重复计算[^4]。 - **共享资源优化**:监控 **shmem** 使用量,避免过度共享导致单点瓶颈。 > 可通过 `smem` 工具或 `/proc/<pid>/smaps` 文件查看详细内存分布[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值