On Friday, July 3, 2020 10:11:53 PM MST Alexey Avramov wrote:
>it should be disabled so it doesn't kill our software
What should people who suffer from the fact that the kernel's OOM killer
does not work, and they are forced to hard reboot (and lose unsaved data)
the computer when it freezes? This is a serious and very common problem
that exists for a long time and has not been fixed out of the box.
I've never managed to get one of my own Fedora machines to the point of
OOMing, and, when I have seen others do it, it's a problem that would have
been solved by having more swap space.
What do you suggest? Should we do nothing?
That's precisely what I suggest.
Of course, we can do nothing and wait for the inclusion of the system-oomd
in the systemd [7]. Just wait.
How is that disabled?
Also look at these discussions:
- Why are low memory conditions handled so badly? [1]
They're not. The system lets you do precisely what you're trying to do.
- Memory management "more effective" on Windows than Linux?
(in preventing
total system lockup) [2]
Windows memory management used to mean that you couldn't map more than
something like 2 GiB per program. Has that been fixed, or is it still
completely broken? I'd certainly not call artificial limitations like that
"more effective".
- Let's talk about the elephant in the room - the
Linux kernel's inability to gracefully handle low memory pressure [3] [4]
Linux handles low memory situations just fine, but it's much better if you
have an appropriately sized swap partition and let the kernel do its job
(don't turn down swappiness)
[5] - How do I prevent Linux from freezing when out of memory? Today
I
(accidentally) ran some program on my Linux box that quickly used a lot of
memory. My system froze, became unresponsive and thus I was unable to kill
the offender. How can I prevent this in the future? Can't it at least keep
a responsive core or something running? [6]
If you didn't mean for the program to use as much memory as it tried to, the
correct solution would be to use cgroups.
--
John M. Harris, Jr.