Linux进程的内存使用情况

在linux下，使用top，ps等命令查看进程的内存使用情况时，经常看到VIRT，RES，SHR等，他们都代表什么意思呢?不同的大小对进程有什么影响呢?这篇文章将来聊一聊这个问题。阅读本篇前建议先阅读Linux内存管理，了解一些Linux下内存的基本概念，如什么是anonymous和file backed映射等。

查看进程所使用的内存

在进程的眼里，所有的内存都是虚拟内存，但是这些虚拟内存所对应的物理内存是多少呢?正如我们在Linux内存管理中所介绍的那样，并不是每块虚拟内存都有对应的物理内存，可能对应的数据在磁盘上的一个文件中，或者交换空间上的一块区域里。一个进程真正的物理内存使用情况只有内核知道，我们只能通过内核开放的一些接口来获取这些统计数据。

top

先看看top的输出(top用到的数据来自于/proc/[pid]/statm)，这里只是摘录了几条数据：

 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND 
2530 root      20   0       0      0      0 S  0.3  0.0   0:02.69 kworker/0:0 
2714 dev       20   0   41824   3700   3084 R  0.3  0.7   0:00.02 top 
3008 dev       20   0   22464   5124   3356 S  0.0  1.0   0:00.02 bash  

VIRT：进程所使用的虚拟内存大小

RES：系统为虚拟内存分配的物理内存大小，包括file backed和anonymous内存，其中anonymous包含了进程自己分配和使用的内存，以及和别的进程通过mmap共享的内存;而file backed的内存就是指加载可执行文件和动态库所占的内存，以及通过private方式调用mmap映射文件所使用的内存(当在内存中修改了这部分数据且没有写回文件，那么这部分内存就变成了anonymous)，这部分内存也可能跟别的进程共享。

SHR：RES的一部分，表示和别的进程共享的内存，包括通过mmap共享的内存和file backed的内存。当通过prive方式调用mmap映射一个文件时，如果没有修改文件的内容，那么那部分内容就是SHR的，一旦修改了文件内容且没有写回文件，那么这部分内存就是anonymous且非SHR的。

%MEM：等于RES/total*100%，这里total指总的物理内存大小。

注意：由于SHR可能会被多个进程所共享，所以系统中所有进程的RES加起来可能会超过总的物理内存数量，由于同样的原因，所有进程的%MEM总和可能超过100%。

从上面的分析可以看出，VIRT的参考意义不大，它只能反应出程序的大小，而RES也不能完全的代表一个进程真正占用的内存空间，因为它里面还包含了SHR的部分，比如三个bash进程共享了一个libc动态库，那么libc所占用的内存算谁的呢?三个进程平分吗?如果启动一个bash占用了4M的RES，其中3M是libc占用的，由于三个进程都共享那3M的libc，那么启动3个bash实际占用的内存将是3*(4-3)+3=6M，但是如果单纯的按照RES来算的话，三个进程就用了12M的空间。所以理解RES和SHR这两个数据的含义对我们在评估一台服务器能跑多少个进程时尤其重要，不要一看到apache的进程占用了20M，就认为系统能跑的apache进程数就是总的物理内存数除以20M，其实这20M里面有可能有很大一部分是SHR的。

注意：top命令输出中的RES和pmap输出中的RSS是一个东西。

pmap

上面top命令只是给出了一个进程大概占用了多少的内存，而pmap能更详细的给出内存都是被谁占用了。pmap命令输出的内容来自于/proc/[pid]/maps和/proc/[pid]/smaps这两个文件，第一个文件包含了每段的一个大概描述，而后一个文件包含了更详细的信息。

这里用pmap看看当前bash的内存使用情况，：

#这里$$代表当前bash的进程ID，下面只显示了部分输出结果 
dev@dev:~$ pmap  $$ 
2805:   bash 
0000000000400000    976K r-x-- bash 
00000000006f3000      4K r---- bash 
00000000006f4000     36K rw--- bash 
00000000006fd000     24K rw---   [ anon ] 
0000000000be4000   1544K rw---   [ anon ] 
...... 
00007f1fa0e9e000   2912K r---- locale-archive 
00007f1fa1176000   1792K r-x-- libc-2.23.so 
00007f1fa1336000   2044K ----- libc-2.23.so 
00007f1fa1535000     16K r---- libc-2.23.so 
00007f1fa1539000      8K rw--- libc-2.23.so 
00007f1fa153b000     16K rw---   [ anon ] 
...... 
00007f1fa196c000    152K r-x-- ld-2.23.so 
00007f1fa1b7e000     28K r--s- gconv-modules.cache 
00007f1fa1b85000     16K rw---   [ anon ] 
00007f1fa1b8f000      8K rw---   [ anon ] 
00007f1fa1b91000      4K r---- ld-2.23.so 
00007f1fa1b92000      4K rw--- ld-2.23.so 
00007f1fa1b93000      4K rw---   [ anon ] 
00007ffde903a000    132K rw---   [ stack ] 
00007ffde90e4000      8K r----   [ anon ] 
00007ffde90e6000      8K r-x--   [ anon ] 
ffffffffff600000      4K r-x--   [ anon ] 
 total            22464K  

这里第一列是内存的起始地址，第二列是mapping的地址大小，第三列是这段内存的访问权限，最后一列是mapping到的文件。这里的地址都是虚拟地址，大小也是虚拟地址大小。

这里的输出有很多的[ anon ]行，表示在磁盘上没有对应的文件，这些一般都是可执行文件或者动态库里的bss段。当然有对应文件的mapping也有可能是anonymous，比如文件的数据段。关于程序的数据段和bss段的介绍请参考elf的相关资料。

上面可以看到bash、libc-2.23.so等文件出现了多行，但每行的权限不一样，这是因为每个动态库或者可执行文件里面都分很多段，有只能读和执行的代码段，有能读写的数据段，还有比如这一行“00007f1fa153b000 16K rw--- [ anon ]”，就是它上面一行libc-2.23.so的bss段。

[ stack ]表示进程用到的栈空间，而heap在这里看不到，因为pmap默认情况下不单独标记heap出来，由于heap是anonymous，所以从这里的大小可以推测出来，heap就是“0000000000be4000 1544K rw--- [ anon ]”。

其实从上面的结果根本看不出实际上每段占用了多少物理内存，要想看到RSS，需要使用-X参数，下面看看更详细的输出：

dev@dev:~$ pmap -X $$ 
2805:   bash 
         Address Perm   Offset Device  Inode  Size  Rss  Pss Referenced Anonymous Shared_Hugetlb Private_Hugetlb Swap SwapPss Locked Mapping 
        00400000 r-xp 00000000  fc:00 390914   976  888  526        888         0              0               0    0       0      0 bash 
        006f3000 r--p 000f3000  fc:00 390914     4    4    4          4         4              0               0    0       0      0 bash 
        006f4000 rw-p 000f4000  fc:00 390914    36   36   36         36        36              0               0    0       0      0 bash 
        006fd000 rw-p 00000000  00:00      0    24   24   24         24        24              0               0    0       0      0 
        00be4000 rw-p 00000000  00:00      0  1544 1544 1544       1544      1544              0               0    0       0      0 [heap] 
    ..... 
    7f1fa0e9e000 r--p 00000000  fc:00 136340  2912  400   83        400         0              0               0    0       0      0 locale-archive 
    7f1fa1176000 r-xp 00000000  fc:00 521726  1792 1512   54       1512         0              0               0    0       0      0 libc-2.23.so 
    7f1fa1336000 ---p 001c0000  fc:00 521726  2044    0    0          0         0              0               0    0       0      0 libc-2.23.so 
    7f1fa1535000 r--p 001bf000  fc:00 521726    16   16   16         16        16              0               0    0       0      0 libc-2.23.so 
    7f1fa1539000 rw-p 001c3000  fc:00 521726     8    8    8          8         8              0               0    0       0      0 libc-2.23.so 
    7f1fa153b000 rw-p 00000000  00:00      0    16   12   12         12        12              0               0    0       0      0 
    ...... 
    7f1fa196c000 r-xp 00000000  fc:00 521702   152  144    4        144         0              0               0    0       0      0 ld-2.23.so 
    7f1fa1b7e000 r--s 00000000  fc:00 132738    28   28    9         28         0              0               0    0       0      0 gconv-modules.cache 
    7f1fa1b85000 rw-p 00000000  00:00      0    16   16   16         16        16              0               0    0       0      0 
    7f1fa1b8f000 rw-p 00000000  00:00      0     8    8    8          8         8              0               0    0       0      0 
    7f1fa1b91000 r--p 00025000  fc:00 521702     4    4    4          4         4              0               0    0       0      0 ld-2.23.so 
    7f1fa1b92000 rw-p 00026000  fc:00 521702     4    4    4          4         4              0               0    0       0      0 ld-2.23.so 
    7f1fa1b93000 rw-p 00000000  00:00      0     4    4    4          4         4              0               0    0       0      0 
    7ffde903a000 rw-p 00000000  00:00      0   136   24   24         24        24              0               0    0       0      0 [stack] 
    7ffde90e4000 r--p 00000000  00:00      0     8    0    0          0         0              0               0    0       0      0 [vvar] 
    7ffde90e6000 r-xp 00000000  00:00      0     8    4    0          4         0              0               0    0       0      0 [vdso] 
ffffffffff600000 r-xp 00000000  00:00      0     4    0    0          0         0              0               0    0       0      0 [vsyscall] 
                                             ===== ==== ==== ========== ========= ============== =============== ==== ======= ====== 
                                             22468 5084 2578       5084      1764              0               0    0       0      0 KB  

• 权限字段多了一个s和p的标记，s表示是和别人共享的内存空间，读写会影响到其他进程，而p表示这是自己私有的内存空间，读写这部分内存不会对其他进程造成影响。
• 输出标示出了[heap]段，并且也说明了后面几个[anon]代表的什么意思(vvar，vdso，vsyscall都是映射到内核的特殊段)，mapping字段为空的都是上一行mapping文件里面的bss段(可是gconv-modules.cache后面有两行anonymous mapping，可能跟共享内存有关系，没有深究)。
• Anonymous列标示出了哪些是并且有多少是Anonymous方式映射的物理内存，其大小小于等于RSS
• RSS列表示实际占用的物理内存大小

top命令输出的SHR内存

最后来看看top命令输出的SHR到底由pmap的哪些输出构成

dev@dev:~$ pmap -d $$ 
3108:   bash 
Address           Kbytes Mode  Offset           Device    Mapping 
0000000000400000     976 r-x-- 0000000000000000 0fc:00000 bash 
00000000006f3000       4 r---- 00000000000f3000 0fc:00000 bash 
00000000006f4000      36 rw--- 00000000000f4000 0fc:00000 bash 
00000000006fd000      24 rw--- 0000000000000000 000:00000   [ anon ] 
0000000000c23000    1544 rw--- 0000000000000000 000:00000   [ anon ] 
...... 
00007f53af18e000      16 rw--- 0000000000000000 000:00000   [ anon ] 
00007f53af198000       8 rw--- 0000000000000000 000:00000   [ anon ] 
00007f53af19a000       4 r---- 0000000000025000 0fc:00000 ld-2.23.so 
00007f53af19b000       4 rw--- 0000000000026000 0fc:00000 ld-2.23.so 
00007f53af19c000       4 rw--- 0000000000000000 000:00000   [ anon ] 
00007ffc5a94b000     132 rw--- 0000000000000000 000:00000   [ stack ] 
00007ffc5a9b7000       8 r---- 0000000000000000 000:00000   [ anon ] 
00007ffc5a9b9000       8 r-x-- 0000000000000000 000:00000   [ anon ] 
ffffffffff600000       4 r-x-- 0000000000000000 000:00000   [ anon ] 
mapped: 22464K    writeable/private: 1848K    shared: 28K 
 
dev@dev:~$ top -p $$ 
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND 
 3108 dev       20   0   22464   5028   3264 S  0.0  1.0   0:00.02 bash 

从上面的输出可看出SHR ≈ RES - writeable/private，其中writeable/private主要包含stack和heap以及可执行文件和动态库的data和bss段，而stack+heap=1544+132=1675，这已经占了绝大部分，从而data和bss段之类的基本上可以忽略了，所以一般情况下，SHR ≈ RES - [heap] - [stack]，由于stack一般都比较小，上面的等式可以进一步约等于：SHR ≈ RES - [heap]。

总结

top命令能看到一个进程占用的虚拟内存空间、物理内存空间以及和别的进程共享的物理内存空间，这里共享的空间包括通过mmap共享的内存以及共享的可执行文件以及动态库。而mmap命令能看到更详细的信息，比如可执行文件和它所链接的动态库大小，以及物理内存都是被哪些段给占用了。

进程占用的虚拟地址空间大小跟程序的规模有关，除了stack和heap段，其他段的大小基本上都是固定的，并且在程序链接的时候就已经确定了，所以基本上只要关注stack和heap段就可以了，由于stack相对heap来说很小，所以只要没什么stack异常，只需要关注heap。

在实际的工作过程中，其实我们更关心的是RSS用了多少，都被谁用了，简单点说，如果我们没有同时启动多个进程(同一个程序)，RSS就是一个很好的实际物理内存使用参考值，但如果是像apache那样同时跑很多个进程，那么RSS减去SHR所占用的空间就是一个很好的实际物理内存占用参考值，当然这都是大概估算值。

要想精确评估一个进程到底占了多少内存，还是很难的，需要对进程的每个段有深入的理解，尤其是SHR部分都有哪些进程在一起共享，不过现在服务器上的内存都是以G为单位的，所以一般情况下大概的估算一下加上合理的测试就能满足我们的需求了。