I believe, and I could be very wrong, that it kills the largest memory process. The problem is that it may not be the problematic process. You could have a well behaved DB that is using a stable 80%, and a runaway process that rapidly fills the remaining 20%, and OOM will kill the DB, and let the out of control process keep consuming memory until it becomes the largest. Then your DB is down and you don't known why.

I like the idea of just killing processes at random though. Determinism is overrated.

Eeny, meeny, miny- YOU

It isn't.

On Linux, the OOM generally weighs 2 things, and based on those, starts killing processes until the system dies or goes back to life.

The 2 things it weighs are memory footprint and how recent the process is.

The reasoning is that, by killing a recently spawned process that is hogging a lot of memory, you will probably kill an unruly app that a user started and not a critical system component. Even in the case of servers with databases that use hundreds of GB of memory, it should in theory not kill them if there's a recent process that has quickly hogged a lot of ram.

Of course, it can still be a bit of a hit or miss (after all, it's a last resource before crashing, and you can't afford much complexity). But for the most part, it works well enough.

Edit: I actually looked at the code. It doesn't check if the process is recent. I don't know where I read that it did. Maybe it was the OOM code for something else.

There are still ways to mark an app as non oom killable, like a critical DB process. But it needs to be manually done.