Memory Usage Analysis of Linux Processes

Article Title: Linux Process memory usage parsing. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

How much memory does process XXX occupy? This is a frequently asked and often incorrect question. Memory Allocation for Linux processes is a complex topic. Linux tools tend to oversimplify this issue, which leads to many misunderstandings and confusions. First, we should discard tools such as ps and top, and then look at such a simple program:

[Root @ pczou] # cat./prog. c

# I nclude

# I nclude

# I nclude

# I nclude

# Define ONEM (1024*1024)

Int func ()

{

Char s [16 * ONEM];

Char * p;

P = malloc (32 * ONEM );

Pause ();

Return 0;

}

Int main ()

{

Printf ("pid: % d \ n", getpid ());

Func ();

Return 0;

}

Among them, the func () function allocates 32 MB of memory and 16 MB of stack.

Run the prog program and the prog will stop at the pause () location. Let's see what ps says:

User pid % CPU % MEM VSZ RSS TTY STAT START TIME COMMAND

Root 4238 0.0 0.0 52396 352 pts/0 S./prog

VSZ refers to the memory size of the process, which is 52366kb;

RSS refers to the memory size in the resident physical memory, which is 352KB.

Generally, the system administrator knows that VSZ does not represent the memory actually used by the process, because some spaces only have a name in the page table, that is, they only have virtual space, the kernel maps virtual pages to real physical pages only when they are actually used. For example, because the 32 MB memory allocated by malloc () in prog. c is not used in the program and no physical memory is allocated, it should not be included in the account of the process.

The memory usage of processes is complicated because:

The memory applied by the process may not be used.

The actually used memory is not necessarily only used by the process itself (such as a dynamic Shared Library)

Therefore, when the restaurant bills a full amount of food, the bill is often full of loopholes, not included in the food that has not been taken, or a single dish to calculate two copies of the money. Ps provides such a "confused" Bill.

The only way to clear the account is to repeat each dish and check whether there are any duplicates. The bill below is much clearer:

Virtual memory: 52396 KB

Tive VM: 52120 KB

Mapped: 352 KB

Valid tive mapped: 76.6 KB

Sole use: 72 KB

Per file memory use

Ld-2.3.4.so: VM 94208 B, M 90112 B, S 8192 B

Prog: VM 8192 B, M 8192 B, S 8192 B

Libc-2.3.4.so: VM 1180 KB, M 221184 B, S 16384 B

It can be seen that although the virtual address space is 52366kb, the actual ing space (a.k. a. allocated) is 352KB, which is consistent with the result given by ps. Let's look at the value of "Effective Mapped", which is only 76.6 KB. The calculation method of this value is:

Effective actual memory usage = exclusive memory of the Process + Shared Memory A/shared A process + Shared Memory B/shared B process +...

For example, for a kde application kontact, the virtual address space of the Qt library is 7 M, and the actual ing space is 4.5 M, that is to say, the actual physical memory size allocated to Qt is 4.5 MB. Assuming that 10 KDE applications are running, the 4.5 M after the A-A should not be recorded on the kontact account. Although the calculation is not very accurate, the "valid tive Mapped" is enough to indicate the actual memory occupied by the process.

OK. Finally, use this method to "settle accounts" for all processes in the system ":

The preceding statistics show that:

Although firefox occupies the largest virtual space, it actually occupies less memory than X Server.

The actual memory used by firefox and its RSS (a.k. a. mapped) the difference is not big, accounting for 99% of RSS; while kontact actually occupies only 63% of RSS's memory, and 27% of memory is shared. From this we can roughly see that the window manager I use is KDE rather than Gnome, why? Because shared libraries such as Qt are shared by many KDE processes.

The sole value can be understood as "private mapped", that is, the memory that may be released after the process exits (for non-Anonymous ing pages, it may remain for a period of time ).