Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
prelockd
Lock executables and shared libraries in memory to improve system responsiveness under low-memory conditions
RAM compression is not magic.
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.
That's just one part of the issue - even after forcefully dropping Linux's caches, WSL has been unable to reclaim the memory back reliably. There has been a recent update that claims to finally fix this.
You might find this package helpful: https://github.com/arkane-systems/wsl-drop-cache
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.
This may or may not preserve your desktop and other important applications in an OOM situation. https://github.com/hakavlad/prelockd