在测试,特别是性能测试或者系统的稳定性测试中,内存的使用情况是一个很重要的监控点,不管是从资源使用的角度还是从发现内存泄露问题的角度。
如果笼统的来看,大概就是两个指标,系统的内存使用率和进程使用的内存。但是现实世界的事情往往没有那么简单,稍微细一点来看其实有很多的科目。本文不是一个全面的关于内存使用的探讨,甚至也不是一个详细的Linux下面进程内存使用情况的分析,尽管这里的实践是基于此的。
这里想做的是稍微细节一点的来看Linux下一个进程的内存使用情况,包括栈和堆。
首先我们从一个简单的C程序开始。且慢,先说一下我试验的环境。
platform: CentOS release 5.6 (Final) Linux localhost.localdomain 2.6.18-238.19.1.el5xen #1 SMP Fri Jul 15 08:57:45 EDT 2011 i686 i686 i386 GNU/Linux
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
[root@localhost test]# cat simple_hello.c
#include <stdio.h>
int main()
{
int i, m = 1024, n = 0 , x;
int a[m];
printf("assign %d values to a[%d]...\n", n, m);
for (i = 0; i < n; i++)
{
a[i] = 100;
}
printf("value assigned.\n");
scanf("%d", &x); /* to hold program.. */
return 0;
}
真是一个很简单的程序,只比hello world复杂一点点。创建一个静态的数组,长度通过m来控制,然后选择性的给部分或者全部的元素赋值,通过n来控制。好吧,这个一个简单的程序能看出什么呢?那我们一起来看看。
在Linux下面,查看一个进程的内存使用我们可以下面的命令来实现,只需把其中的[pid]换成进程实际的pid。
# cat /proc/[pid]/status
为了方便,我们把查找pid和看内存整合成一条命令,后面这将是我们唯一的测试工具。
cat /proc/`ps -ef|grep hello | grep -v grep | awk '{print $2}'`/status | grep -E 'VmSize|VmRSS|VmData|VmStk|VmExe|VmLib'
在这里我们关注VmSize|VmRSS|VmData|VmStk|VmExe|VmLib 这个6个指标,下面有一些简单的解释。
VmSize(KB) : 虚拟内存大小。整个进程使用虚拟内存大小,是VmLib, VmExe, VmData, 和 VmStk的总和。
VmRSS(KB): 虚拟内存驻留集合大小。这是驻留在物理内存的一部分。它没有交换到硬盘。它包括代码,数据和栈。
VmData(KB): 程序数据段的大小(所占虚拟内存的大小), 堆使用的虚拟内存。
VmStk(KB): 任务在用户态的栈的大小, 栈使用的虚拟内存
VmExe(KB): 程序所拥有的可执行虚拟内存的大小,代码段,不包括任务使用的库
VmLib(KB) :被映像到任务的虚拟内存空间的库的大小
Ok, 测试开始了。
首先,我们固定m的值为409600,相当于400K,因为数组的元素是int型,在我的环境里面是4Byte,所以真个数组的大小为1600KB。
m固定化,我们不断调整n的大小,重写编译,执行,然后用上面的命令查看内存的使用情况,这样我们得到了下面这个表格。
从这里我们可以得到几个信息:
1. 静态的数组使用的空间被分配到VmStk,也就是栈区。
2. 在数组没有初始化的时候并没有实际占用虚拟内存,看VmRss,但是整个虚拟内存的大小还是分配了,VmSize。
接下来我们做另一个测试,让n=m,调整m的大小,也就是说调整数组的大小,然后初始化所有的元素。
这样我们得到了下面的表。
![](http://hi.csdn.net/attachment/201109/24/0_1316851656vuvp.gif)
从这个表中,我们可以看出:
1. 栈的使用确实和数组的size相关,但是有个起始预分配的大小,应该是编译器的优化。
2. VmRSS和VmSize跟着一起在涨。
嗯,是跟着在涨,但是有个问题,栈的空间是有限的,通过这个程序或者你查看系统的设置你可以找到上限。在我的这台机器上上限是8MB,每个进程,所以这里如果m的值大于2048000,就会出segmentation fault的错误。当然你也可以调整系统的设置,比如通过
# ulimit -s 10240将上限调为10MB。但是这个终究不能调得很大,因为对系统会有影响。所以编程中太大的静态数组不是有个好主意。
栈的大小限制还是蛮严格的,好吧,那我们来看看程序可以使用的另一类存储空间,堆(heap)。关于堆和栈的区别可能是一个常被问道的问题,你在很多地方可以找到答案。
OK,我们继续我们的实验,考虑到现在很多系统的后台用C++来写,我们也把测试程序换成C++的。好吧,我承认其实没有太大的区别,只是申请内存的方式不太一样了。
[root@localhost test]# cat hello.cpp
#include <iostream>
using namespace std;
int main()
{
cout<<"New some space for array, assign value"<<endl;
int m = 409600, n = 409600;
int *p = new int[m];
for (int i = 0; i < n; i++)
{
p[i] = 100;
}
cout<<"value assigned."<<endl;
int x;
cin>>x; //hold program
}
这个我们使用的是动态的数组,也就是说数组的内容空间是我们显式的通过new通过向系统申请的。测试工具还是上面的命令行。
延迟我们的风格,首先固定m的值,这里是409600,400K,然后调整n的值,看情况是怎样的。
一些观察的结果:
1. VmData的大小约为1600KB,因为每个元素4Byte,系统还有一些别的使用。
2. n控制有多少数组的元素被初始化,这也影响了VmRSS的大小。
整个VmSize的大小并不受初始化范围的影响,这个结果和之前栈的实验中看到的现象很类似,只不过这里换成了VmData。
接下来我们让n=m,然后两个一起调整。
可以看出:
1. VmData的size在增长,VmRSS也在跟着一起增长。但是VmRSS一开始分配的余量就比较大,所以VmData刚开始的增长并未立即导致VmSize的改变。
2. VmSize也跟着一起增长,应该的。
请注意这里发生了一些很奇怪的现象,那就是当m=40960的时候,你会发现VmData的值比m=20480的时候还要小,很不正常。
实验了很多次,我发现在一个特定的区间里面VmData并未按照m的值增长,而且下降了,然后又开始增长。和同事一起check了一下,目前的解释是装载程序做了一些tricky的事情,也可能是某种优化,具体的还不是很清楚。
在实际的产品代码,特别是后台的Linux服务器程序中,通常会大量的申请和释放内存,动态的,使用的就是我们这里提到的VmData,堆上的内存。Ok,你知道了,我要说的是memory leak的问题。通过观察VmData和VmRSS,我们能够很明确的察觉内存泄露的问题。
前面在分析栈的时候我们提到了系统对栈的大小有上限,比如我的系统默认是8MB。那么有个问题就是,那么堆呢?
嗯,这个部分其实就涉及到操作系统的内存管理的策略和方法,是个很大的问题,推荐看一下《深入理解计算机系统》相关的章节或者关于现代的操作系统的书籍。这里我们简单做了一下实验。
我的实验机器的内存是1GB,一个Linux的虚拟机。
当我们设置 m = n = 204800000的时候,相当于要申请800MB的内存。
我们产品status的时候发现VmData > VmRSS, 这在前面m=n的情况下从来没有出现过。
VmSize: 802784 kB
VmLck: 0 kB
VmHWM: 684384 kB
VmRSS: 676808 kB
VmData: 800064 kB
所以一定是有些事情发生变化了。于是我们看了一下系统的内存,以及SWAP的使用情况。
Mem: 900096k total, 893180k used, 6916k free, 1012k buffers
Swap: 2096472k total, 147320k used , 1949152k free, 33012k cached
发现系统的物理内存已经快用了,还留了一些给系统,然后开始使用SWAP了,大家知道这里的SWAP其实是磁盘文件。
在这种情况下,我们也许可以更容易理解驻留内存的意义,以及为什么内存不够会导致性能的明显下降。
如果进一步把m=n加到300M,也是申请1.2GB的内存(已经大于所有物理内存的数目),可能会更明显。
VmSize: 1202784 kB
VmLck: 0 kB
VmHWM: 814064 kB
VmRSS: 793588 kB
VmData: 1200064 kB
Mem: 900096k total, 894128k used, 5968k free, 1104k buffers
Swap: 2096472k total, 541812k used, 1554660k free, 13616k cached