3 ms·
Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15 https://lkml.org/lkml/2019/8/4/15 It's because linux is a toy OS. Specifically, it overcommit
by joshAg 22d ago
Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15 https://lkml.org/lkml/2019/8/4/15
It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for.
Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing.
If it really bothers you OpenBSD (edit: thanks for the reminder TimTheTinker) and Illumos don't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.
- nicman23 22d agoor use the system's oom ?
- joshAg 22d agoThat's what's breaking the system and causing freezes. You can tune it a bit to minimize when it happens, but not get rid of the issue entirely.
- SoftTalker 22d ago... which then kills sshd, locking you out of being able to get in and do any recovery.
- nicman23 21d agothe system will restart sshd?
- joshAg 21d agothe system will kill whatever it damn well pleases. You can tune it with priorities to ask it to try to not kill that, and once it kills your sshd once, you'll probably configure it to exempt sshd from being OOM killed at all. That doesn't fix the memory pressure or hanging or stalling, but you'll at least be able to log into the box still instead of dragging out a serial cable.
- nicman23 20d agoare you using systemd or some other init ?
- joshAg 19d agoboth. freebsd has init scripts. ubuntu has systemd. this guide should help make it less likely for sshd or your login shell to get killed: https://ianlpaterson.com/blog/oom-lockout-ssh-survival-hardening/ https://ianlpaterson.com/blog/oom-lockout-ssh-survival-harde...
- rwmj 21d agoAll I want is the oomkiller to always kill firefox. Somehow that's very difficult to achieve.
- lokar 21d agoThe oom killer is a monkey with a gun. It’s a last resort when you were going to crash (or worse, hang) anyway. You should have a much better “plan A” to avoid this situation.
- throw0101d 22d ago> It's because linux is a toy OS. Specifically, it overcommits memory …by default. It can be disabled via a sysctl: * https://www.kernel.org/doc/Documentation/vm/overcommit-accounting https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
- joshAg 21d agoYou're right. I'm glad the very next sentence in my comment landed. The problem with turning it off is that the system and applications have been architected assuming that it will be on, so things like fork/execing a memory heavy processes or allocating memory inside a cgroup (which still pretends overcommit is enabled and there's still no way to disable that assumption) that used to work fine might break with no good way to get them to work again. This comment (and siblings) have more specifics: https://news.ycombinator.com/item?id=27794237#27795199 https://news.ycombinator.com/item?id=27794237#27795199
- deleted 21d ago[deleted]
- TimTheTinker 21d agoIllumos also doesn't overcommit, if you want the more modern OS descended from Solaris.
- joshAg 21d agocan't believe i forgot to mention them! Updating the parent for visibility