linux – Why is the OOM idle and the kernel freezes when memory runs out?

Question:

Throughout the entire time of using linux distributions, I noticed that if a memory leak occurs in some program or I accidentally leave, for example, htop with strace open for a day, the system will freeze when memory is exhausted and it will not be possible to switch to the console or, for example, enable / disable " Caps Lock "(the indicator on the keyboard will simply not change its state).
Freezing occurs gradually during the process of memory exhaustion, at first iowait rises and it becomes noticeable that the system slows down a little, then, with continued memory exhaustion, iowait tends to 100% and the system starts to freeze more, and then generally tightly and almost irrevocably, in the process of memory exhaustion and raising iowait in parallel begins to be in the active state longer and longer, the drive operation indicator, up to constant activity, without changing the state.
You can "hang up" only by somehow freeing memory, when the system completely freezes, I only got it by pressing the "System Request" key sequence (they must be included in sysctl) – ALT-SysRQ-F, this calls OOM Killer, it frees up memory and the system gradually begins to go into a normal state of operation, the OOM Killer itself without pressing this combination is called only when memory overcommit is disabled via sysctl, and with memory overcommit enabled, OOM Killer does not work, no matter how much I wait and no matter how I tried to configure the sysctl parameters.
Everyone, whom I would not ask on the merits, could not answer me, only offered to increase the number. memory, but I have no problems with this, I have enough of it and I only experienced freezing situations in abnormal situations.
I have a theory that the kernel starts cyclically dropping some caches to disk in search of free memory and freezes because of this, but this is just a theory, I would like to read explanations from a person who understands this.
PS This of course all happens when swap is disabled

Answer:

A large iowait is most likely due to the fact that the system has to constantly re-read the pages in memory to find those that can be freed. the more memory the active process has, the more CPU time it takes.

OOM is called if the current state of the system answers the following questions:

  • Is there enough swap space (nr_swap_pages> 0)? If yes, then not OOM
  • Has it been more than 5 seconds since the last failure? If yes, then not OOM
  • Did we fail at the last second? If not, then not OOM
  • If there were no 10 crashes, at least in the last 5 seconds, we are not OOM
  • Has the process been killed in the last 5 seconds? If yes, then not OOM

Those. it turns out that to call OOM Killer, it is necessary that the system does not have enough memory for fresh processes (or for the one who ate it, request as much as there is in the system at once – in a large chunk) This is necessary so that OOM Killer kills a newly launched process with a memory leak and does not touch old, solid processes that just eat up a lot of memory.

Sources:

https://www.kernel.org/doc/gorman/html/understand/understand016.html http://catap.ru/blog/2009/05/03/about-memory-oom-killer/

Scroll to Top