Resolver erros de falta de memória na VM

Efeitos de OOM

Quando o Dataproc em VMs do Compute Engine encontram erros de falta de memória (OOM, na sigla em inglês):

As VMs mestre e de trabalho congelam por um período.
Os erros de OOM das VMs mestres fazem com que os jobs falhem com o erro "tarefa não adquirida".
Os erros de OOM da VM de trabalho causam uma perda do nó no HDFS, o que atrasa a execução do job do Dataproc.

Controles de memória de fios

O Yarn oferece três tipos de controles de memória:

Com base em enquetes (legado)
Estrito
Elastic

Por padrão, o Dataproc não define yarn.nodemanager.resource.memory.enabled para ativar os controles de memória do JupyterLab pelos seguintes motivos:

O controle de memória rigoroso pode causar o encerramento de contêineres quando houver memória suficiente se os tamanhos dos contêineres não estiverem configurados corretamente.
Os requisitos de controle de memória elástico podem afetar negativamente a execução do job.
Os controles de memória do Nest podem não conseguir evitar erros de OOM quando os processos consomem memória de forma agressiva.

Proteção de memória do Dataproc

Quando uma VM de cluster do Dataproc sofre pressão de memória, a proteção de memória do Dataproc encerra processos ou contêineres até que a condição de OOM seja removida.

A proteção de memória do Dataproc é fornecida para os seguintes nós de cluster nas versões de imagem do Dataproc no Compute Engine:

Papel	1.5	2.0	2.1
VM principal	1.5.74+	2.0.48+	todas
VM do worker	Indisponível	2.0.76+	2.1.24+
VM do pool de drivers	Indisponível	2.0.76+	2.1.24+

Como identificar encerramentos da proteção de memória do Dataproc

Os processos que a proteção de memória do Dataproc encerra são encerrados com o código 137 ou 143.
Encerramento do nó de trabalho:
- O Dataproc incrementa a métrica cumulativa dataproc.googleapis.com/node/problem_count e define reason como ProcessKilledDueToMemoryPressure.
- Se o Cloud Logging estiver ativado, o Dataproc gravará um registro google.dataproc.oom-killer com a mensagem "Um processo foi encerrado devido à pressão da memória: [nome do processo]".
- Se esse contêiner for encerrado, o Dataproc escreverá a seguinte mensagem no gerenciador de recursos Crashlytics: "[ID do contêiner] saiu com o código 137, o que pode significar uma pressão de memória em [ID do nó]".
Encerramento do nó do pool de drivers ou mestre: o driver do job falha com Driver received SIGTERM/SIGKILL signal and exited with [INT] code.

Soluções de OOM

Esta seção oferece recomendações para encerramentos de jobs e contêineres que podem resultar de problemas de OOM.

O job falha com "O driver recebeu o sinal SIGTERM/SIGKILL e saiu com o código [INT]"

Recomendações:

Se os clusters tiverem um pool de drivers, aumente driver-required-memory-mb para o uso da memória do job inicial.
Se o cluster não tiver um pool de drivers, recrie-o, diminuindo o número máximo de jobs simultâneos, que é calculado como (total master memory in MB - 3584MB) / driver-size-mb. É possível diminuir esse número:
- Configurar dataproc:dataproc.scheduler.max-concurrent-jobs ou
- Defina dataproc:dataproc.scheduler.driver-size-mb como um número maior (o padrão é 1024MB).
Considere usar um tipo de máquina de nó mestre com mais memória.

Contêiner fechado com o código de saída 137 ou 143

Recomendações:

Se a proteção de memória do Dataproc tiver encerrado o contêiner. Consulte Como identificar encerramentos da proteção de memória do Dataproc:
- Verifique se os tamanhos dos contêineres estão configurados corretamente.
- Considere diminuir a yarn.nodemanager.resource.memory-mb. Essa propriedade controla a quantidade de memória usada para programar contêineres FHIR.
- Se os contêineres do job falharem consistentemente, verifique se o desvio de dados está causando um aumento no uso de contêineres específicos. Nesse caso, reparticione o job ou aumente o tamanho do worker para acomodar outros requisitos de memória.