3 ms·
For me, on the desktop, thrashing overload is the most common way the Linux system effectively crashes... (I've left it overnight a few times, sometimes it reco
by silon42 10mo ago
For me, on the desktop, thrashing overload is the most common way the Linux system effectively crashes... (I've left it overnight a few times, sometimes it recovered, but not always).
I'm not disabling overcommit for now, but maybe I should.
- Tuna-Fish 10mo agodisabling overcommit does not fix trashing. Reducing the size of your swap does.
- silon42 10mo agoYes, but not fully, it may still thrash on mmaped files (especially readonly ones).
- PunchyHamster 10mo agoIt's not gonna change anything. But you might get interested into software like earlyoom and similar, that basically tried to preempt oomkiller and kill something before it gets to sluggish state
- webstrand 10mo agoThat thrashing is probably executable pages getting evicted, and then having to be reloaded from disk when the process resumes. Even with no swap and overcommit disabled, you'll still get thrashing before the OOM killer gets triggered. I recommend everyone to enable linux's new multi-generational LRU, that can be configured to trigger the OOM when the workingset of the last N deciseconds doesn't fit in memory. And <https://github.com/hakavlad/nohang https://github.com/hakavlad/nohang> has some more suggestions.
- minitech 10mo agoSysRq+F to trigger the OOM killer manually might help (has to be enabled with the kernel.sysrq sysctl, see https://docs.kernel.org/admin-guide/sysrq.html#how-do-i-enable-the-magic-sysrq-key https://docs.kernel.org/admin-guide/sysrq.html#how-do-i-enab...).