How does the OOM killer decide which process to kill first?
If memory is exhaustively used up by processes, to the extent which can possibly threaten the stability of the system, then the OOM killer comes into the picture.
NOTE: It is the task of the OOM Killer to continue killing processes until enough memory is freed for the smooth functioning of the rest of the process that the Kernel is attempting to run.
The OOM Killer has to select the best process(es) to kill. Best here refers to that process which will free up the maximum memory upon killing and is also the least important to the system.
The primary goal is to kill the least number of processes that minimizes the damage done and at the same time maximizing the amount of memory freed.
To facilitate this, the kernel maintains an oom_score
for each of the processes. You can see the oom_score
of each of the processes in the /proc
filesystem under the pid
directory.
$ cat /proc/10292/oom_score
The higher the value of oom_score
of any process, the higher is its likelihood of getting killed by the OOM Killer in an out-of-memory situation.
How is the OOM_Score
calculated?
In David's patch set, the old badness() heuristics are almost entirely gone. Instead, the calculation turns into a simple question of what percentage of the available memory is being used by the process. If the system as a whole is short of memory, then "available memory" is the sum of all RAM and swap space available to the system.
If instead, the OOM situation is caused by exhausting the memory allowed to a given cpuset/control group, then "available memory" is the total amount allocated to that control group. A similar calculation is made if limits imposed by a memory policy have been exceeded. In each case, the memory use of the process is deemed to be the sum of its resident set (the number of RAM pages it is using) and its swap usage.
This calculation produces a percent-times-ten number as a result; a process which is using every byte of the memory available to it will have a score of 1000, while a process using no memory at all will get a score of zero. There are very few heuristic tweaks to this score, but the code does still subtract a small amount (30) from the score of root-owned processes on the notion that they are slightly more valuable than user-owned processes.
One other tweak which is applied is to add the value stored in each process's oom_score_adj variable, which can be adjusted via /proc. This knob allows the adjustment of each process's attractiveness to the OOM killer in user space; setting it to -1000 will disable OOM kills entirely, while setting to +1000 is the equivalent of painting a large target on the associated process.
References
http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326
Ramesh
Updated on September 18, 2022Comments
-
Ramesh almost 2 years
This answer explains the actions taken by the kernel when an OOM situation is encountered based on the value of
sysctl vm.overcommit_memory
.When
overcommit_memory
is set to 0 or 1,overcommit
is enabled, and programs are allowed to allocate more memory than is really available.Now what happens when we run out of memory in this situation? How does the OOM killer decide which process to kill first?
-
fpmurphy over 9 yearsI believes that the values are 1 an 2 - not 0 and 1.
-
Rui F Ribeiro over 7 yearsFrom here serverfault.com/questions/606185/… , 0 and 1 are the correct values.
-
Jarek Przygódzki over 7 yearsThere is an excellent description available at linux-mm.org/OOM_Killer
-
Derek Lewis about 7 yearsAccording to kernel.org/doc/Documentation/vm/overcommit-accounting 0, 1, and 2 are all valid values.
-
DeveloperACE over 3 yearsanother interesting link oracle.com/technical-resources/articles/it-infrastructure/…
-
-
neverMind9 over 5 yearsDoesn't niceness also play a role?
-
Ravi Naik over 3 yearsThere's also a useful
oom_score_adj
-
Sida Zhou over 3 yearsDoes niceness play a role?