3 ms·
You don't even need that, the kernel OOM killer would take care of this eventually. Unless its something like Java where the garbage collector would begin to bu
by aeyes 4y ago
You don't even need that, the kernel OOM killer would take care of this eventually. Unless its something like Java where the garbage collector would begin to burn CPU.
- j3th9n 4y agoThe OOM killer doesn't restart (randomly, unless configured) killed processes, it just kills.
- pkolaczk 4y agoIf it's deployed in K8s, it would be restarted automatically after dying.
- TylerE 4y agoThen you have two problems.
- ce4 4y agoUnless the OOM-killer kills the wrong process. Ages ago we had a userspace filesystem (gpfs) that was of course one of the oldest processes around and it consumed lots of RAM. When the oom killer started looking for a target, of course one of the mmfsd processes was selected and it resulted in instantaneous machine lockup (any access to that filesystem would be blocked forever in the system call which depended on the userspace daemon to return, alas never returning). Was funny to debug
- j3th9n 4y agoYou can prevent a process from being killed by OOM killer: https://backdrift.org/oom-killer-how-to-create-oom-exclusions-in-linux https://backdrift.org/oom-killer-how-to-create-oom-exclusion...