Como o assassino da OOM decide qual processo matar primeiro?

Esta resposta explica as ações executadas pelo kernel quando uma situação de OOM é encontrada com base no valor de sysctl vm.overcommit_memory.

Quando overcommit_memorydefinido como 0 ou 1, overcommitestá ativado e os programas têm permissão para alocar mais memória do que realmente está disponível.

Agora, o que acontece quando ficamos sem memória nessa situação? Como o assassino da OOM decide qual processo matar primeiro?

Se a memória for exaustivamente usada pelos processos, na medida em que possa ameaçar a estabilidade do sistema, o assassino da OOM entrará em cena.

NOTA: É tarefa do assassino OOM continuar matando processos até que seja liberada memória suficiente para o bom funcionamento do restante do processo que o Kernel está tentando executar.

O OOM Killer precisa selecionar o melhor processo (s) para matar. O melhor aqui se refere àquele processo que liberará a memória máxima ao matar e também é o menos importante para o sistema.

O objetivo principal é eliminar o menor número de processos que minimiza o dano causado e ao mesmo tempo maximizar a quantidade de memória liberada.

Para facilitar isso, o kernel mantém um oom_scorepara cada um dos processos. Você pode ver oom_scorecada um dos processos no /procsistema de arquivos no piddiretório

$ cat /proc/10292/oom_score

Quanto maior o valor de oom_scorequalquer processo, maior a probabilidade de ser morto pelo OOM Killer em uma situação de falta de memória.

Como é OOM_Scorecalculado?

No conjunto de patches de David, as antigas heurísticas badness () desapareceram quase inteiramente. Em vez disso, o cálculo se transforma em uma pergunta simples de qual porcentagem da memória disponível está sendo usada pelo processo. Se o sistema como um todo estiver com pouca memória, "memória disponível" será a soma de toda a RAM e espaço de troca disponível para o sistema.

Se, em vez disso, a situação do OOM for causada pelo esgotamento da memória permitida para um determinado grupo de cpuset / controle, "memória disponível" será a quantidade total alocada para esse grupo de controle. Um cálculo semelhante é feito se os limites impostos por uma política de memória forem excedidos. Em cada caso, o uso de memória do processo é considerado a soma do conjunto residente (o número de páginas de RAM que ele está usando) e o uso de troca.

Este cálculo produz um número de porcentagem-dez-dez como resultado; um processo que usa cada byte da memória disponível terá uma pontuação de 1000, enquanto um processo que não usa memória obterá uma pontuação igual a zero. Existem muito poucos ajustes heurísticos nessa pontuação, mas o código ainda subtrai uma pequena quantia (30) da pontuação dos processos de propriedade da raiz, na noção de que eles são um pouco mais valiosos do que os processos de propriedade do usuário.

Um outro ajuste aplicado é adicionar o valor armazenado na variável oom_score_adj de cada processo, que pode ser ajustada via / proc. Esse botão permite o ajuste da atratividade de cada processo para o OOM killer no espaço do usuário; defini-lo como -1000 desativará completamente as mortes por OOM, enquanto defini-lo como +1000 é o equivalente a pintar um grande alvo no processo associado.

Referências

http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326