Actions
coordination #32734
closed[functional][epic][u][new test] OOM handling
Start date:
2018-03-03
Due date:
% Done:
0%
Estimated time:
Description
Motivation¶
OOM (out-of-memory) handling in GNU/Linux is suboptimal and one can come into a thrashing situation easily where it is hard to come out except for rebooting the system. We should have a test procedure to explore the current limits of the systems we develop and even be able to raise feature requests next to bugs.
Acceptance criteria¶
- AC1: We have a testing procedure to induce OOM conditions, at best automatic
- AC2: We understand the current limits of GNU/Linux to be able to create either bug reports or feature requests
Suggestions¶
- Start a https://en.wikipedia.org/wiki/Fork_bomb and try to recover, e.g. in bash
:(){ :|:&};:
or maybe better a "memory bomb?": https://codegolf.stackexchange.com/a/24488 . might be too synthetic though - A test for magic-sysrq-f
Further references¶
- https://superuser.com/questions/248707/how-do-i-quickly-stop-a-process-that-is-causing-thrashing-due-to-excess-memory?rq=1
- https://www.reddit.com/r/linux/comments/75gyrz/a_tribute_to_altsysrqf/
- https://unix.stackexchange.com/questions/271765/machine-freezes-once-it-hits-swap-space-under-heavy-load
- https://en.wikipedia.org/wiki/Magic_SysRq_key which for example also mentions what works for s390x over a 3270 console: +- followed by the desired key
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/194676 describes why openSUSE (sic) has many actions disabled by default
Actions