Linux process memory analysis and memory leak location

In the development of Linux products, it is often necessary to pay attention to the system memory usage, and to evaluate the memory usage of a single process, so that we can choose the appropriate machine configuration to deploy our products.

Linux itself provides some tools to facilitate the implementation of these requirements, to see the process real-time resource top tool, more detailed process memory stack situation, PMAP tools, Linux Process runtime state information will also be saved in the proc directory, the corresponding process ID directory, there is a lot of information, The process memory is discussed first.

Most people on the Internet, the Linux system in memory allocation: when memory is sufficient, try to use memory to cache some files, so as to speed up the process, and when the memory is low, the corresponding memory recycling policy to recover cache memory for the process to use.

Although the development under the Linux platform, but not familiar with Linux memory management, but the above statement, can be verified by the following methods:

One, system memory.

The Meminfo file in the proc directory describes the usage of the system memory, the available physical memory =memfree+buffers+cached, which is the case of Suse10:

Memtotal is full of physical memory, my virtual machine is configured with 1G of memory, memfree+buffers+cached = 438752, and about 430M is available, because my machines run only Apache and Redis processes.

When Memfree is not enough, the kernel writes cached and buffered memory back to the fallback memory via a writeback mechanism (Pdflush thread), or it can explicitly release the cache memory manually

Echo 3 >/proc/sys/vm/drop_caches

After release, buffers and cached tables were much smaller, Memfree became much larger, memfree+buffers+cached three and about 430M.

Second, process memory

In a 32-bit operating system, each process has 4G of virtual memory space, where 0~3GB is the private user space for each process, which is invisible to other processes in the system. 3~4GB is a Linux kernel space that is shared by all the processes and cores of the system. You can view the process memory situation by accessing the relevant files under/proc/{pid}/.

If a process contains multiple threads, multiple threads share a process's user-state virtual address space, and the virtual address space contains several areas, mainly in the following areas:

1. The code snippet of the current execution file, which is called the text segment.

2, the execution of the data section of the file, the main store to execute the file to use the global variables, static variables. (Global and Static)

3. A heap that stores global variables and dynamically generated data. Heap

4, the stack for saving local variables and implementing function calls. Stack

5. Using Mmap method to map memory segments in virtual address space

This is the case with the Redis process on my machine,

The first line: from the R-XP that its permissions are read-only, executable, the memory address corresponding to the execution of the file

Code snippet, the code snippet of the program needs to be loaded into memory before it can be executed. Because it is read-only, it will not

is modified so that it is shared throughout the system.

The second line: from the rw-p know that its permissions are read-write, non-executable, the memory address corresponds to the data segment of the execution file, the execution of the file to use the global variables, static variables.

The third line: from the RWXP know that its permissions are read-write, executable, address space up, and does not correspond to files, is a heap segment, the process uses malloc application memory placed in the heap segment. Each process has only one heap segment, either the main process or the memory requested by a different thread, which is reflected to the heap segment of the process. The heap segment grows upward, and the maximum can grow to a position of 1GB, that is, 0x40000000, if greater than 1GB,GLIBC will use the Mmap method, request a piece of memory for the heap.

Line four: The memory address of the shared library where the program is connected.

Line five: is the virtual address space mapped in mmap mode.

Line sixth to seventh: is the thread's stack address segment, each thread's stack size is 16K.

Line eighth: Is the stack area of the process. With respect to the stack segment, each thread has one, and if there are multiple threads in the process, it contains multiple stacks.

Three, the current system total memory statistics

1. The total memory occupied by the process can be calculated from the maps table above.

2, when the system is running, the application layer related files will be attached to the Tmpfs file system, this part of the sea think system is about 13M, this part of the memory is the cache method of statistics, but this part of the memory cache can not be recovered by the policy or explicit call release.

3. The memory occupied by the root file system RAMDisk.

4, the current system reserves the size of memory, you can see/proc/sys/vm/min_free_kbytes to get or modify the size of this memory.

5, of course, when the system is running, you should also leave a certain amount of memory for the hard disk read and write cache or network load when the allocation of SKB, etc., generally need more than 30M.

Iv. some revelations about debugging memory leaking class problems

When the process requests memory, it is actually the built-in memory manager in GLIBC that receives the request, and as the process requests more memory, the memory manager sinks into the kernel through system calls, allocating more memory to the process.

For heap segment management, the kernel provides two system calls BRK and mmap,brk for changing the top address of the heap, while Mmap assigns a block of virtual address space to the process.

When a process requests memory from GLIBC, if the amount of memory requested is greater than a threshold, GLIBC uses MMAP to allocate a virtual address space for the process instead of BRK to extend the pointer to the top of the heap. By default, this threshold is 128K and can be modified by a function.

#include <malloc.h>

intmallopt (int param, int value)

The values of Param are m_mmap_threshold and M_mmap_max respectively.

Value is measured in bytes.

M_mmap_threshold is a GLIBC request for large memory thresholds, larger than the threshold of memory requests, the memory manager uses MMAP system calls to request memory, and if less than that threshold memory request, the memory manager uses BRK system calls to extend the heap top pointer.

M_mmap_max is the maximum number of address segments that are allocated in the process using MMAP.

If, during the actual debugging process, you suspect that a memory leak has occurred somewhere, you can view the maps table for that process, see if the virtual address space of the process's heap segment or mmap segment continues to increase, and if so, it is likely that a memory leak has occurred, and if the MMAP segment virtual address space continues to increase, You can also see the size of the virtual address space for each segment, so that you can determine how much memory is being requested, and can play a good role in debugging memory leak class issues.

Transferred from: http://blog.csdn.net/babykakaluo/article/details/9763605

Linux process memory analysis and memory leak location