A bit of learning and practice about process memory usage

Original URL:

http://blog.csdn.net/superqa/article/details/6817539

In testing, especially performance testing or system stability testing, memory usage is an important monitoring point, whether from the point of view of resource usage or from the point of view of memory leak problems.

If you look at it in general, it's about two metrics, the memory usage of the system, and the memory used by the process. But the real world things are not so simple, a little bit more to see in fact there are a lot of subjects. This article is not a comprehensive discussion of memory usage, nor even a detailed analysis of the process memory usage of Linux below, although the practice here is based on this.

What you want to do here is a little bit more detail to see the memory usage of the next Linux process, including stacks and heaps.

First we start with a simple C program. Wait a minute, let's talk about the environment I experimented with.
Platform:centos Release 5.6 (Final) Linux localhost.localdomain 2.6.18-238.19.1.el5xen #1 SMP Fri June 08:57:45 EDT 2 011 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 ... */
return 0;
}

It's a very simple program, just a little bit more complicated than Hello world. Creates a static array, which is controlled by M, and optionally assigns a value to some or all of the elements, and is controlled by N. Well, this is a simple procedure to see what it is. Let's look at it together.

Under Linux, look at the memory of a process using the following commands we can implement, just replace the [PID] in the process of the actual PID.
# Cat/proc/[pid]/status
For convenience, we integrate the lookup PID and look at the memory into a single command, which will be our only Test tool.
cat/proc/' Ps-ef|grep Hello | Grep-v grep | awk ' {print $} '/status | Grep-e ' vmsize| vmrss| vmdata| vmstk| vmexe| Vmlib '

Here we pay attention to vmsize| vmrss| vmdata| vmstk| vmexe| Vmlib The 6 indicators, here are some simple explanations.
vmsize (KB):Virtual memory size. The entire process uses virtual memory size, which is the sum of Vmlib, Vmexe, Vmdata, and VMSTK.
Vmrss (KB):Virtual memory resides in the collection size. This is part of the physical memory that resides. It is not swapped to the hard drive. It includes code, data, and stacks.
Vmdata (KB):The size of the program data segment (the size of the virtual memory), and the virtual memory used by the heap.
Vmstk (KB):The size of the task in the user state stack, the virtual memory used by the stack

Vmexe (KB): the size of the executable virtual memory that the program has, the code snippet, excluding the libraries used by the task

Vmlib (KB): the size of the library of virtual memory space that is imaged to the task

Ok, the test begins.

First of all, we fixed the value of M 409600, equivalent to 400K, because the elements of the array is int, in my environment is 4Byte, so the true number of the size of the array is 1600KB.

M-Fixed, we constantly adjust the size of n, rewrite compile, execute, and then use the above command to view the memory usage, so we get the following table.

From here we can get a few messages:

1. The space used by the static array is assigned to the VMSTK, which is the stack area.

2. When the array is not initialized and does not actually occupy virtual memory, see VMRSS, but the entire virtual memory size is allocated, vmsize.

Next we do another test, let n=m, adjust the size of M, that is, resize the array, and then initialize all the elements.

So we get the following table.

From this table, we can see that:

1. The use of the stack is actually related to the size of the array, but there is a start to the size of the allocation, should be the compiler optimization.

2. Vmrss and Vmsize followed together in a rise.

Well, it's following up, but there's a problem, the stack space is limited, and you can find the upper limit by using this program or by looking at the system settings. The upper limit on my machine is8MB, each process, so here if the value of M is greater than 2048000, the segmentation fault error occurs. Of course you can also adjust the system settings, such as through the # ulimit-s 10240
Adjust the upper limit to 10MB. But this cannot be adjusted very much, because it will affect the system. So it's not a good idea to have too large a static array in programming.


The size limit of the stack is pretty strict, OK, so let's look at another type of storage space that the program can use, the heap (heap). The difference between stacks and stacks may be a frequently asked question, and you can find answers in many places.

OK, we continue our experiment, considering that many system backstage uses C + + to write, we also change the test program to C + +. Well, I admit that there is not much difference, but the way to apply for memory is not the same.

[Root@localhost test]# Cat Hello.cpp
#include <iostream>
using namespace Std;

int main ()
{
cout<< "New some space for array, assign value" <<endl;

Intm = 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
}

We are using a dynamic array, which means that the content space of the array is explicitly applied to the system through new. The test tool is still the command line above.

Delay our style, first fix the value of M, here is 409600,400k, then adjust the value of N to see what the situation is.

The results of some observations:

1. The size of the vmdata is about 1600KB, because each element 4Byte, the system has some other uses.

2. N controls how many arrays of elements are initialized, which also affects the size of the Vmrss.

The size of the entire vmsize is not affected by the initialization range, and this result is similar to what was seen in the previous stack experiment, except that it was replaced with Vmdata.

Next we let n=m, and then two adjustments together.

You can see:

1. The size of Vmdata is growing and vmrss is growing along with it. But Vmrss initially allocated a relatively large margin, so Vmdata's initial growth did not immediately lead to vmsize changes.

2. Vmsize also followed along with the growth, should be.

Note that there are some very strange phenomena here, that is, when m=40960, you will find that the Vmdata value is smaller than the m=20480, is not normal.

Many times, I found that in a particular interval vmdata did not grow in the value of M, and fell, and then began to grow. Check with colleagues, the current explanation is that the loader has done some tricky things, it may be some kind of optimization, the specific is not very clear.