It does allow you to save RAM and might prevent you from hitting swap for a while longer, but it won't save you if your working set is just too large and/or difficult to compress. Apps like web browsers with multiple tabs open might be easier to compress, a game with multiple different assets that are already in a variety of compressed formats, less so.
The Linux Kernel also has a bunch of optimizations (Kernel same-page merging, for example, among others) that do not require compression(although you could argue that same-page merging _is_ a form of compression).
The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.
> which always takes minutes in my experience
It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.
I have always found Linux to behave far more gracefully than Windows (OSX is debatable) in low memory conditions, and relatively easy to tune. Windows is a swapping psycho and there's little you can do. OSX mostly does the right thing, until it doesn't.
> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.
I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.
> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.
Yeah. Exactly. But as the thread says, why aren't those things set up automatically?
As an additional data point, my usual OOM experience on Linux is also a completely frozen system until I get frustrated enough to power cycle the machine.
Has anyone transitioned from this being their observed behavior to something more tolerable? What did you change to avoid this problem?
Same page merging only works for KVM, as that's the only case that enables it without intervention that nothing else supports. It's MADVISE for everything non-KVM, and no applications are compiled with support for telling the kernel "hey, it's OK to dedupe me". The only way to get KSM to work with userspace applications is to use LD_PRELOAD to inject the necessary bits (https://github.com/unbrice/ksm_preload) or to use a custom kernel that has a patch and extra daemon to globally enable KSM for everything (https://codeberg.org/pf-kernel/uksmd).
I really wish this was a standard, configurable sysctl. There are many container environments (and heck, even browsers) that would benefit from this, and I cannot see any real downside.
Didn't say it was magic. System slows down more as you use more RAM compression, so you have time to respond and close some apps. Without it I find I often am working at a thousand miles an hour, not noticing anything amiss, and then suddenly, brick wall, out of memory and I can't do anything at all.
OOMKiller jumps into action pretty late. I'm on Fedora, thus running the systemd-oomd service, but even with this new service the system will lock up for a minute or two before the greedy process is killed.
I think with modern browsers, on memory constrained systems (think 4GB of RAM) this is easier to encounter than in the past. As someone who programs in Haskell from time to time I think I'm more familiar with Linux OOM behavior than most.
If someone wants to experience this easily with Haskell just run the following in ghci
>The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong.
I've never seen a Linux system not lock up on OOM. At work or at home the instant it starts swapping you might as well restart. Of course it has to kill the SSH daemon rather than the process using 98% of the memory.
>I have always found Linux to behave far more gracefully than Windows
Windows just gets sluggish for a few seconds. You can even still move the cursor when that happens!
It does allow you to save RAM and might prevent you from hitting swap for a while longer, but it won't save you if your working set is just too large and/or difficult to compress. Apps like web browsers with multiple tabs open might be easier to compress, a game with multiple different assets that are already in a variety of compressed formats, less so.
The Linux Kernel also has a bunch of optimizations (Kernel same-page merging, for example, among others) that do not require compression(although you could argue that same-page merging _is_ a form of compression).
The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.
> which always takes minutes in my experience
It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.
I have always found Linux to behave far more gracefully than Windows (OSX is debatable) in low memory conditions, and relatively easy to tune. Windows is a swapping psycho and there's little you can do. OSX mostly does the right thing, until it doesn't.