É recomendado definir OOMScoreAdjust = 1000 no systemd para um serviço substituível?

Question

O systemd possui a opção OOMScoreAdjust , que permite ajustar a pontuação do killer do processo iniciado.

Para citar a documentação do systemd :

OOMScoreAdjust=

Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory pressure very likely). See proc.txt for details.

Na minha configuração, estou implantando um servidor NodeJs na AWS. Ao lado do servidor Node, não há muito mais em execução na instância do EC2 (espere o monitoramento e os processos essenciais do SO). Existem verificações de integridade do ELB, que eventualmente substituirão instâncias quebradas do EC2.

Ainda assim, gostaria de saber se é considerado uma boa prática aumentar OOMScoreAdjust para fazer o kernel preferir eliminar o processo do servidor Node se houver problemas de memória, já que ele pode ser reiniciado automaticamente. No systemd, poderia ser assim:

OOMScoreAdjust=1000
Restart=always

Eu tenho que admitir que meu entendimento é limitado. Meu entendimento atual é que isso provavelmente não fará uma diferença real, e é melhor deixar os padrões em vigor:

• Se o processo de drenagem de memória for o servidor Node, ele provavelmente será eliminado de qualquer maneira.
• Se o culpado for outro processo, reiniciar o servidor do Nó não ajudará e as verificações de integridade do ELB deverão, eventualmente, substituir a instância.

Ainda assim, estou curioso para saber se alguém com um entendimento melhor já pensou nisso. A ativação seria apenas uma linha no script systemd. E, em caso de dúvida, prefiro que o kernel mate o processo Node do que qualquer serviço de sistema aleatório.

    

Answer 1

No caso de um servidor com um único processo, ele provavelmente não fará uma grande diferença, mas isso pode realmente brilhar se você tiver um processo que freqüentemente vaze memória.

Por exemplo, na área de trabalho, o Firefox tende a usar mais e mais memória até que o OOM-killer seja invocado, e invariavelmente ele decide que o Xorg está usando mais memória e o mata, derrubando toda a sua área de trabalho apenas o navegador que precisava ser reiniciado.

Então, neste caso, configurar o programa com vazamento para ter uma pontuação OOM de 1000 e reiniciar imediatamente não será um problema, porque ele será morto primeiro e quando recarregar, não estará usando tanta memória quanto antes , liberando memória em geral.

Se o processo tiver um uso de memória razoavelmente constante, é improvável que isso importe (mas certamente não vai doer), mas se estiver vazando, provavelmente resultará em uma recuperação mais rápida do que ter o AWS da AWB percebendo o problema e construir um novo VM.