3 ms·
Along these lines, I had a fun encounter with the Linux OOM killer the other day. The scenario was roughly this. Process A consumes 55% of available memory but
by sigil 15y ago
Along these lines, I had a fun encounter with the Linux OOM killer the other day.
The scenario was roughly this. Process A consumes 55% of available memory but has stable memory usage and has been running for days. Process B has a memory allocation bug and rapidly goes from low memory usage to consuming the remaining 45%. Which process gets killed first on my system? Process A.
I'm not up on the latest OOM scoring heuristics (they keep changing), but if it's only looking at instantaneous memory usage when things go critical, and not the trend, that seems dumb. I'd be willing to bet memory leaks are an especially common cause of OOM.
...then again, putting all these heuristics in the kernel with no tunables seems dumber. Does anyone know if delegating to a userspace OOM killer is possible or being contemplated?
- rcxdude 15y agoit seems the latest kernel doesn't use the more complex heuristics that it used to (preserving longer running tasks, for example) and just goes off the proportion of memory used by the process, with a 3% bonus for the superuser. However it does also adjust the score by the value in /proc/pid/oom_score_adj (which can completly disable or completely favour the process) and so you could probably write a userspace daemon which updated this value based on whatever heuristics you want (although you'd have to do it before the OOM condition).