Como você define a "causa" da situação da OOM? É o processo que usa mais memória? Talvez você tenha um banco de dados que sempre precise de 3 GB de memória para rodar e, assim, use a maior parte da memória da máquina. É a "causa" do problema? Provavelmente não.
Em última análise, a causa do problema é "Uma situação inesperada que pode ou não ter sido culpa do administrador do sistema".Às vezes você pode saber; por exemplo, se você tivesse a configuração de contabilidade do processo (+ 1 to @JamesHannah) e você visse 3000 processos httpd ou sshd (e isso era incomum), provavelmente você poderia culpar o daemon.
Com isso em mente, apresento comentários da The Source:
/*
* oom_badness - calculate a numeric value for how bad this task has been
* @p: task struct of which task we should calculate
* @p: current uptime in seconds
*
* The formula used is relatively simple and documented inline in the
* function. The main rationale is that we want to select a good task
* to kill when we run out of memory.
*
* Good in this context means that:
* 1) we lose the minimum amount of work done
* 2) we recover a large amount of memory
* 3) we don't kill anything innocent of eating tons of memory
* 4) we want to kill the minimum amount of processes (one)
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
*/
"Portanto, o candidato ideal para a liquidação é um processo recentemente iniciado, não privilegiado, que junto com seus filhos usa muita memória, foi legal, e não faz E / S não processada. Algo semelhante a um kernel paralelo nohup'd build (que não é uma má escolha, pois todos os resultados são salvos em disco e muito pouco trabalho é perdido quando um 'make' é finalizado). "
Bloco de comentários e citação descarada roubada de link