认真分析下进程的内存，说说VSZ、RSS、PSS

进程占用的内存可以有以下这些类型：

1. 自身的代码
2. 共享库的代码
3. 运行过程分配的堆和栈
4. 通过mmap映射的磁盘文件内容

1. 虚拟内存与物理内存

这里要区分两个概念，虚拟内存和物理内存。物理内存对于进程来说是透明的，进程直接操作的是虚拟内存。而数据和代码是存放在真实的物理内存的，之所以进程在虚拟内存中寻址可以获取数据，是由于虚拟内存与物理内存存在着映射关系。

当我们的进程向系统申请内存时，比方通过malloc方法，得到的其实是虚拟内存，假如进程没有使用这些虚拟内存，那么它们是不会和物理内存关联起来的。比方假如我们malloc 10MB的内存，但是只用了一个byte的，那么进程实际得到的只有一个页的物理内存，也就是4096byte的内存空间。当物理内存被换出到磁盘（swap out），虚拟内存对应的地址还是有效的，假如寻址到这些地址，对应的物理内存就会被换入到内存（swap in）。

虚拟内存是连续的，而物理内存却不肯定。

2. 共享的内存

从进程自身的角度看，虚拟内存是进程独立的，所有内存都是私有的，包括自身代码、共享库、堆栈等，它不用关心共享内存的事情。但实际上在物理内存的层面，很多东西是可以共享的，比方共享的代码库（.so）、自身代码甚至是自身运行时私有的堆栈内存。

2.1 共享库

同一个共享库的代码在物理内存中只会存在一份，这块内存会映射到不同进程的虚拟内存中，对各个进程来说，就像是自己私有的内存一样，而对于系统来说，则是节省了内存的资源。

2.2 进程自身的代码

同样，同一份代码运行起来的多个进程是共享这些代码的内存的，由于可执行代码类型的内存页是只读的（除非是debugger模式），没有必要复制多份，因而在实际场景中，当我们启动一个大应用程序后，再启动它的另一个实例，第二次启动会快很多，这就是由于其代码已经在内存中了，无需再重新加载一遍。

2.3 进程自身的私有内存

假如从一个进程fork出一个子进程，那么父进程的私有内存（比方堆栈）则会与子进程共享，但会被标记成（copy-on-write），意思是假如两个进程都没有修改这些内存页，那么这些内存页在两个进程间就是共享的，但假如某个进程要修改某个页了，那么这个页就会先被复制一份，再被修改。

3. 进程内存的数据统计

在OSX系统，可以运行以下命令来查看某个进程内每一块内存的类型（mapped file、Stack内存、malloc内存、代码的__DATA或者者__TEXT段等），以及大小、能否共享或者者copy-on-write等。

sudo vmmap <pid>

假如只是关注RAM的内存，可以加上-resident参数：

sudo vmmap -resident <pid>

比方指定Firefox进程，有如下输出：

可以看到，Firefox进程的代码和库代码加载了108MB__TEXT段数据，字体支持（ATS）需要33MB内存，但只有2.5MB真正加载在物理内存中，它通过MALLOC申请了256MB内存，并且247MB在物理内存中，它有14MB用于栈内存，但只用了248KB。

4. 进程内存大小的度量方法

提到进程消耗的内存大小，我们或者多或者少听到VSZ、RSS、PSS，那么它们代表的是什么呢？有了上述的知识背景，现在来分析或者许能更加清晰。

4.1 VSZ（Virtual Memory Size）

指的是虚拟内存的大小，进程运行理论需要的内存大小，用这个来表示进程消耗了多少内存其实没有太大的意义，由于它包含了未被加载到实际内存中的空间。举个例子，如果有个文本编辑器叫做emacs，它有个编辑xml文件的功能，但这个功能比较少被用到，由于客户一般情况下是编辑普通的文本，因而没有必要一启动就把这个功能的代码加载到内存中。

除非客户真实用到某个页，否则系统不会把这个页加载到内存，这其实称为demand paging feature。

来看一下上面这个例子中虚拟内存工作的流程。首先启动应用程序，系统为进程分配了运行编辑xml所需要的虚拟内存，但并没有真正把这些功能所在的页加载到物理内存。当进程真正调用到编辑xml的功能，CPU上的MMU模块将会告诉系统，对应的虚拟内存页发生缺页了，那么系统就会暂停运行中的进程，把对应的页加载到内存，再把这些物理内存页映射到虚拟内存上，最后让应用程序从暂停的地方继续执行。对于进程来说，它是不知道自己被暂停了的，它只要要简单地认为对应的功能已经加载在虚拟内存上了，并使用它就好了。

虚拟内存形容了进程运行时所需要的总内存大小，包括了那些还没有被加载到实际内存中的代码和数据。

4.2 RSS（Resident Set Size）

RSS表示了进程中真正被加载到物理内存中的页的大小。但是用它来表示进程占用的内存大小也不太合适，由于还有个共享代码库的概念（Shared Libraries）。

比方libxml2.so这个程序库，有多个进程会用到它，而系统在物理内存只会加载一遍这个代码库，而后这块物理内存会被映射到不同进程的虚拟内存空间中，对于单独的进程来说，就像是这个库只加载在自己的虚拟内存中一样，不需要关心它能否与其它进程共享。

而进程的RSS是包含这块共享库的内存空间的，因而假如简单把系统中所有进程的RSS相加的话，结果是比系统总的内存大的，由于共享库占的内存被计算了多遍。

4.3 PSS（Proportional Set Size）

PSS在VSS的基础上，将共享库的内存按使用的进程个数平均分成多份。如果有N个进程使用libxml2.so这个库，这个库加载了200K代码在内存中，那么每个进程的PSS值中有（200 / N）K 的大小是这个共享库贡献的。

假如把系统中所有进程的PSS值加起来，就等于系统所有进程占用的内存总大小。

但是PSS并不是在所有的Linux系统中都有提供的，比方ps命令中就没有PSS值，而Android的adb shell dumpsys meminfo <pid>命令即可以看到进程的PSS值。

4.4 总结一下三种度量方法

假如要度量进程占用的内存大小，较好的选择是使用PSS，用RSS也行，不过要注意有些内存是和别的进程共享的。

再举个例子总结一下前面三个概念，比方一个进程有500K的代码并且链接了2500K的共享库，而后有200K的堆栈分配。其中有400K自身的代码、1000K的共享库以100K的堆栈内存被加载在实际内存（RAM）中，并且系统中一共有两个进程用了同样的共享库。那么：

VSZ：500K + 2500K + 200K = 3200K
RSS：400K + 1000K + 100K = 1500K
PSS：400K + (1000K / 2) + 100K = 1000K

5. 命令执行结果

在Android的adb shell中执行ps命令的结果：

1. 执行adb shell ps：

2. 执行adb shell dumpsys meminfo com.android.calendar：

6. 参考文献：

1. https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management
2. https://web.archive.org/web/20120520221529/http://emilics.com/blog/article/mconsumption.html
3. https://stackoverflow.com/questions/118307/a-way-to-determine-a-processs-real-memory-usage-i-e-private-dirty-rss