Classic blog
| Types of | article |
|---|---|
| Relations slab, slub of | The difference between SLUB and SLAB |
| Systematic introduction kernel memory leak detection | Linux memory management (22) memory test technology , Linux memory usage and the tools and methods of analysis of memory leaks |
| drop_cache application | liunx of Slab relatively high occupancy problem |
| slub, slab memory leak diagnosis differentiated | How https://blog.csdn.net/dolp leak diagnosis SLAB |
| Judgment slub, slab whether a memory leak | linux by meminfo and locate memory leaks slab |
| Examples | Kernel memory leak know , SLUB leak analysis |
| Introduction and use tools | kmemleak use |
Trigger slab recovery
Bowen: https://www.iteye.com/blog/fengbin2005-2218722
above investigation to a Linux system memory for a large number of dentry_cache, why are there so many dentry_cache it?
-
First, figure out dentry_cache concept and function: cache directory entries, in order to improve the processing efficiency of the Linux directory entry objects designed; it records the mapping between the directory entry to the inode. Therefore, when the application is launched stat system call, it will create the corresponding dentry_cache items (Furthermore, if every file stat is nonexistent file, then there will always be a large number of new dentry_cache items are created).
-
The current server is a cluster node storm, first thought of storm-related work processes, strace about the storm of worker processes found very frequently stat system call occurs, and stat files are always new file name:
sudo strace -fp <pid> -e trace=stat -
Further observed that worker process will be frequent storm created in the local directory, open, close, delete files heartbeat, every second a new file name:
sudo strace -fp <pid> -e trace=open,stat,close,unlink
These are the reasons why the system is so much dentry_cache lies.
A strange phenomenon
By observing the / proc / meminfo found, slab memory is divided into two parts:
SReclaimable // 可回收的slab
SUnreclaim // 不可回收的slab
At that time the status of the server is: slab partially occupied by memory, most of the displays are SReclaimable, that is to say can be recycled.
However, by slabtop observed OBJS slab main memory portion (dentry_cache) almost all ACTIVE, the display is used in a state of 100%.
The OBJ SIZE the ACTIVE SLABS the USE OBJS the OBJ / SLAB the CACHE NAME SIZE
13,926,348 13,926,348 773 686 100% 18 is 0.21K 3494744K dentry_cache
334 040 262 056 78% 40 33404K buffer_head, 0.09K 8351
151040 30208 150 537 99% 0.74K. 5 120832K ext3_inode_cache
show why recyclable, but it is in the ACTIVE state? Linux kernel up to people seeking enthusiastic after seeing explain:
Will be due ACTIVE state, resulting in dcache not automatically freed recovered it?
The system automatically recovered dcache
The previous section, we have already mentioned, most of the slab of memory on the server is SReclaimable recyclable state, then we can not let him to the operating system to automatically trigger recovery operations in a certain time? The answer is yes.
Modify the trigger recovered cache
Check some relevant information on Linux dcache found in the operating system into memory after a critical threshold, triggering kswapd kernel processes work was to be released, this threshold is calculated as follows:
-
First, grep low / proc / zoneinfo, following results were obtained:
low 1 low 380 low 12067 -
The above three together, multiplied by 4KB, is this threshold value, calculated by this method was found after the recovery threshold current server is only 48MB, so it is difficult to see this phenomenon, the practice could not wait recovery, the operating system will hang live not responded.
-
The following methods can be called up by big this threshold: the vm.extra_free_kbytes set vm.min_free_kbytes and as large as the / proc / zoneinfo the corresponding low threshold value will be doubled, while the high threshold value will grow, in order to analogy.
$ sudo sysctl -a | grep free_kbytes vm.min_free_kbytes = 39847 vm.extra_free_kbytes = 0 ######1GB $ sudo sysctl -w vm.extra_free_kbytes=836787 ####系统中 没有vm.extra_free_kbytes 这个参数,修改下面的参数 $ /sbin/sysctl -w vm.min_free_kbytes=836787 -
For example, when the low threshold value is set to 1GB time, when the system free memory is less than 1GB, observed kswapd process started (process state from Sleeping changed Running), while dcache started by the system recovery, until the system free of memory is between low and high thresholds threshold, stopping the regeneration.
