3 ms·
You do understand that no amount of RAM will fix a buggy or leaky application? That buying more ram has weeks of latency or is altogether not possible by hardwa
by AstralStorm 7y ago
You do understand that no amount of RAM will fix a buggy or leaky application? That buying more ram has weeks of latency or is altogether not possible by hardware or politics?
If you know you want to keep bare Xorg alive with no window manager, taskbar or desktop, there's oom_adj magic knob, accessible by systemd.
And memory cgroups.
But on a shell server, you actually want to kill that Xorg but preserve background tasks.
- pmontra 7y agoI understand that an out of control application can't be made to behave by any amount of RAM. But it's out of control, so if it dies it's (kind of) OK. I saw memory leaks in production and the usual workaround is rebooting the application or the OS once per day. Sometimes more than that. And then warming up the caches ect. On a shell server there is no Xorg running, not even on machines with a partial of complete X11 installation because (example) they need fonts to generate PDFs. I just checked a few of them. On a desktop/laptop Xorg is the last thing I want to hang or be killed because it makes it harder to check what went wrong. I'll look into oom_adj, thanks.
- pmontra 7y agoI googled oom_adj and found https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 I run the script to display the oom_score_adj of the processes running on my laptop. It's 0 for all of them except the blink based browers (including Slack). For those processes it's either 200 or 300. It means that they'll be the first ones to go. Apparently their developers played nice with the system.