5 ms·

Killing the user's graphical session is terrible. On the other hand, not having a userspace OOM killer means (meant?) that if your system runs out of memory, i

by jraph 4y ago

Killing the user's graphical session is terrible. On the other hand, not having a userspace OOM killer means (meant?) that if your system runs out of memory, it will become so slow as to be totally unresponsive and the only thing you can do is to reboot. Which is even worse. Is that still true today or did the kernel OOM killer improved? How does earlyoom compare against systemd-oomd?

bigpeopleareold 4y ago
I'll just say that earlyoom is much more bearable out-of-the-box than what this sounds like and much better than waiting for Linux to trigger the internal OOM killer (or trying to remember the SysRq key sequence to just trigger it. I always forget and don't have it close by when I need it :) ). I had to play around with the configuration a little to get it to match the conditions I could potentially get an OOM, but when it did reach it on my desktop, it would kill something like Slack, definitely not the whole X session. (FWIW, this happened when building a large Java project, that would burst with memory usage at certain stages of a build, on my computer that just has 16gb. Outside of managing OOM, it's something to play around with before giving up and just upping the RAM. :) )
- thecosmicfrog 4y ago
  Alt+SysRq+REISUB Or, as a mnemonic: Reboot Even If System Utterly Borked* *Being Irish, I prefer "Banjaxed" for the last word, personally.
  - bigpeopleareold 4y ago
    Ah yeah, that :D But that's a full terminate process/filesystem sync/shutdown + restart ... You got me to look it up: Alt-SysRq-F just for the kernel oom_killer ... On ThinkPads, that's: Press Fn-Alt-S, then release Fn-S, then press the desired letter. Result from dmesg: "[154256.637037] sysrq: This sysrq operation is disabled." Bleh. Didn't work when you needed it :) Of course these can be enabled, but earlyoom is soo much easier than remembering the OOM dance or the REISUB dance (particularly if it is just an OOM :D)
nullc 4y ago
> it will become so slow at to be totally unresponsive and the only thing you can do is to reboot. It's been well over a decade since I've seen that kind of behavior. Storage devices became much lower latency and the kernel swapper got much smarter.
- doliveira 4y ago
  Oh, definitely not my experience with 16 GB of RAM.
- kaba0 4y ago
  It still happens on an 8GiB laptop even with zram (I should probably buy a ram stick at this point).
- Avamander 4y ago
  Can't confirm. I have more than 32GiB of memory and very fast storage and I see freezes more often than something being killed. The worst I saw was LUKS/dm-crypt being unable to allocate memory and slightly corrupting one of the mounted filesystems. Linux Desktop in OOM situations is absolutely trash.
5- 4y ago
anecdotally, i've found that on a low-ram laptop having zram (i.e. compressed swap in ram) helps a lot, smoothing out the memory exhaustion. things start to get slower very gradually (as now swap churn means constant (de)compression rather than disk access), allowing you or the oom killer time to act.
- kaba0 4y ago
  I can also share this sentiment, though I have to add that unfortunately the kernel can still get into a state where it constantly churns pages to-from disk swap as well, freezing so hard that not even alt+printscr+f (oom killer) can react. Reisub works though. It seems to get fixed/reintroduced by version to version..
- pflanze 4y ago
  I found (no hard evidence though) that zswap behaves even more nicely, at least on a Raspberry Pi (and on top of that is easier to configure, it's just an on/off setting that can be done via procfs or boot argument, zswap.enabled=1).

by jraph 4y ago

bigpeopleareold 4y ago

I'll just say that earlyoom is much more bearable out-of-the-box than what this sounds like and much better than waiting for Linux to trigger the internal OOM killer (or trying to remember the SysRq key sequence to just trigger it. I always forget and don't have it close by when I need it :) ). I had to play around with the configuration a little to get it to match the conditions I could potentially get an OOM, but when it did reach it on my desktop, it would kill something like Slack, definitely not the whole X session. (FWIW, this happened when building a large Java project, that would burst with memory usage at certain stages of a build, on my computer that just has 16gb. Outside of managing OOM, it's something to play around with before giving up and just upping the RAM. :) )

thecosmicfrog 4y ago
Alt+SysRq+REISUB Or, as a mnemonic: Reboot Even If System Utterly Borked* *Being Irish, I prefer "Banjaxed" for the last word, personally.
- bigpeopleareold 4y ago
  Ah yeah, that :D But that's a full terminate process/filesystem sync/shutdown + restart ... You got me to look it up: Alt-SysRq-F just for the kernel oom_killer ... On ThinkPads, that's: Press Fn-Alt-S, then release Fn-S, then press the desired letter. Result from dmesg: "[154256.637037] sysrq: This sysrq operation is disabled." Bleh. Didn't work when you needed it :) Of course these can be enabled, but earlyoom is soo much easier than remembering the OOM dance or the REISUB dance (particularly if it is just an OOM :D)

nullc 4y ago

> it will become so slow at to be totally unresponsive and the only thing you can do is to reboot. It's been well over a decade since I've seen that kind of behavior. Storage devices became much lower latency and the kernel swapper got much smarter.

doliveira 4y ago
Oh, definitely not my experience with 16 GB of RAM.
kaba0 4y ago
It still happens on an 8GiB laptop even with zram (I should probably buy a ram stick at this point).
Avamander 4y ago
Can't confirm. I have more than 32GiB of memory and very fast storage and I see freezes more often than something being killed. The worst I saw was LUKS/dm-crypt being unable to allocate memory and slightly corrupting one of the mounted filesystems. Linux Desktop in OOM situations is absolutely trash.

5- 4y ago

anecdotally, i've found that on a low-ram laptop having zram (i.e. compressed swap in ram) helps a lot, smoothing out the memory exhaustion. things start to get slower very gradually (as now swap churn means constant (de)compression rather than disk access), allowing you or the oom killer time to act.

kaba0 4y ago
I can also share this sentiment, though I have to add that unfortunately the kernel can still get into a state where it constantly churns pages to-from disk swap as well, freezing so hard that not even alt+printscr+f (oom killer) can react. Reisub works though. It seems to get fixed/reintroduced by version to version..
pflanze 4y ago
I found (no hard evidence though) that zswap behaves even more nicely, at least on a Raspberry Pi (and on top of that is easier to configure, it's just an on/off setting that can be done via procfs or boot argument, zswap.enabled=1).