先用虚拟内存还是物理内存_认真分析下进程的内存，说说VSZ、RSS、PSS

最新推荐文章于 2024-06-14 13:48:48 发布

weixin_39956036

最新推荐文章于 2024-06-14 13:48:48 发布

阅读量363

点赞数

文章标签：先用虚拟内存还是物理内存

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

自身的代码
共享库的代码
运行过程分配的堆和栈
通过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

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

sudo vmmap -resident

比如指定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 命令就可以看到进程的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命令的结果：

执行 adb shell ps ：

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