OOM principle analysis

Usually there are two conditions for OOM: 1. no more pages can be allocated in the VM (note that linuxkernel delays page allocation policies and alloc only when used; therefore, malloc + memset is valid ). 2. insufficient user address space. in this case, 32-bit machines and userspace exceed 3 GB, which is unlikely to happen on 64-bit machines. There are generally two conditions for OOM:

1. no more pages can be allocated in the VM (note that linuxkernel is the page allocation delay policy and alloc only when used; therefore, malloc + memset is valid ).

2. insufficient user address space. in this case, 32-bit machines and userspace exceed 3 GB, which is unlikely to happen on 64-bit machines.

The following describes the OOM mechanism by analyzing the oom_kill.c code in the kernel. OOM corresponds to two functions in the kernel: out_of_memory () and pagefault_out_of_memory (). all functions are called _ out_of_memory ().

_ Out_of_memory:

1. call select_bad_process to select a process to be killed;

2. call oom_kill_process to kill the select process.

The select_bad_process function scans the entire process list:

1) skip kernelthread, process that does not occupy mem, INIT process, and process that is set to OOM_DISABLE. you can set/proc/ The value of oom_adj is adjusted by/oom_adj. the value range of oom_adj is [-17,15]. the larger the value, the more likely it is to be killed by oom. the process set to OOM_DISABLE (-17) will not be killed by oom.

2) call the badness () function for other processes to calculate the score. The highest score is selected. Badness () function compute score (points) has the following factors:

A) the score starts with the total_vm occupied by the process;

Points = mm-> total_vm;

B) if the process has sub-processes, add total_vm/2 occupied by the sub-processes to the process score;

Points + = child-> mm-> total_vm/2 + 1;

C) the score is inversely proportional to the cpu_time and run_time of the process;

Points/= int_sqrt (cpu_time );

Points/= int_sqrt (run_time ));

D) if nice is greater than 0, the score doubles;

If (task_nice (p)> 0) points * = 2;

E) reduce the score for processes with super permissions and those with direct disk interaction;

If (CAP_SYS_ADMIN | CAP_SYS_RESOURCE | CAP_SYS_RAWIO) points/= 4;

F) if the process does not overlap with the current process in the memory, the score is reduced;

If (! Has_intersects_mems_allowed (p) points/= 8;

G) the final score is calculated based on the oom_adj of the process;

Points <= abs (oom_adj );

The function of oom_kill_process is simple:

Force_sig (SIGKILL, p );

We can see that the signal SIGKILL is actually executing the kill-9pid, because SIGKILL cannot be captured.

You can configure the OOM policy using the following two parameters:

/Proc/sys/vm/overcommit_memory

/Proc/sys/vm/overcommit_ratio

The value of overcommit_memory is [0-2]:

0: indicates overcommit in inspired mode (you can submit an alloc page application that exceeds the physical memory size), which is also the default setting;

1: overcommit is always allowed. this mode is the easiest to trigger oom;

2: cannot overcommit. In this mode, the maximum User Space is limited to: SS + RAM * (r/100), SS is the swap size, r is the value set by overcommit_ratio, and the range is: [0-100].

There is a mem_notify mechanism that can send signals to the application process when the memory is insufficient, so that the application process can release the memory. if the memory cannot be released, oomkiller is called, however, versions later than linux 2.6.28 cannot be used, so we should avoid using OOM to manage and monitor the application memory.