This is one of the very few cases where Windows works better than Linux and has for decades. There's a lot Windows is shit at, but if there's one thing it handles surprisingly well, it's running out of memory.
Crashing the high-load program is one option. The whole system is unresponsive so it's very unlikely you'll get to ever get to recover the data anyway. It's better to lose some data than to lose everything.
Though, what I'd REALLY like to see is something that triggers SIGSTOP to a process whenever it:
A. Is consuming the majority of the total used RAM.
B. The total available RAM and SWAP has exceeded 95%.
By doing this, it's a win-win: your system remains stable and usable, and you still get a chance to recover and/or SIGCONT the process. There could be a single file in the /etc folder that controls the behavior of this (so for example, maybe you want to increase the limit to 99%, or use SIGKILL instead of SIGSTOP, or ignore SWAP percentages).
Any reason why this solution couldn't be done?
Originally posted by Saverios
View Post
Though, what I'd REALLY like to see is something that triggers SIGSTOP to a process whenever it:
A. Is consuming the majority of the total used RAM.
B. The total available RAM and SWAP has exceeded 95%.
By doing this, it's a win-win: your system remains stable and usable, and you still get a chance to recover and/or SIGCONT the process. There could be a single file in the /etc folder that controls the behavior of this (so for example, maybe you want to increase the limit to 99%, or use SIGKILL instead of SIGSTOP, or ignore SWAP percentages).
Any reason why this solution couldn't be done?
Comment