Como o assassino da OOM decide qual processo matar primeiro?

Question

Esta resposta explica as ações tomadas pelo kernel quando uma situação OOM é encontrada com base no valor de% código%.

Quando sysctl vm.overcommit_memory é definido como 0 ou 1, overcommit_memory é habilitado e os programas podem alocar mais memória do que realmente disponível.

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

    

Answer 1

Se a memória é exaustivamente usada por processos, na medida em que pode ameaçar a estabilidade do sistema, o assassino da OOM entra em cena.

OBSERVAÇÃO: É a tarefa do OOM Killer continuar matando os 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 tem que selecionar o (s) melhor (es) melhor (is) processo (s) para matar. Melhor aqui refere-se ao processo que irá liberar o máximo de memória 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_score para cada um dos processos. Você pode ver o oom_score de cada um dos processos no sistema de arquivos /proc sob o diretório pid .

$ cat /proc/10292/oom_score

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

Como o OOM_Score é calculado?

In David's patch set, the old badness() heuristics are almost entirely gone. Instead, the calculation turns into a simple question of what percentage of the available memory is being used by the process. If the system as a whole is short of memory, then "available memory" is the sum of all RAM and swap space available to the system.

If instead, the OOM situation is caused by exhausting the memory allowed to a given cpuset/control group, then "available memory" is the total amount allocated to that control group. A similar calculation is made if limits imposed by a memory policy have been exceeded. In each case, the memory use of the process is deemed to be the sum of its resident set (the number of RAM pages it is using) and its swap usage.

This calculation produces a percent-times-ten number as a result; a process which is using every byte of the memory available to it will have a score of 1000, while a process using no memory at all will get a score of zero. There are very few heuristic tweaks to this score, but the code does still subtract a small amount (30) from the score of root-owned processes on the notion that they are slightly more valuable than user-owned processes.

One other tweak which is applied is to add the value stored in each process's oom_score_adj variable, which can be adjusted via /proc. This knob allows the adjustment of each process's attractiveness to the OOM killer in user space; setting it to -1000 will disable OOM kills entirely, while setting to +1000 is the equivalent of painting a large target on the associated process.

Referências

link link