Resolver erros de falta de memória da VM

Nesta página, você encontra informações sobre erros de falta de memória (OOM) do Dataproc em VMs do Compute Engine e explica as etapas que podem ser seguidas para resolver esses erros.

Efeitos do erro de OOM

Quando as VMs do Dataproc no Compute Engine encontram erros de falta de memória (OOM, na sigla em inglês), os efeitos incluem as seguintes condições:

• As VMs mestre e de worker ficam congeladas por um período.

• Os erros de falta de memória (OOM) das VMs principais fazem com que os jobs falhem com erros de "tarefa não adquirida".

• Os erros de falta de memória da VM worker causam a perda do nó no HDFS do YARN, o que atrasa a execução do job do Dataproc.

Controles de memória do YARN

O Apache YARN oferece os seguintes tipos de controles de memória:

• Baseado em pesquisa (legado)
• Estrito
• Elastic

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

• O controle estrito de memória pode causar o encerramento de contêineres quando há memória suficiente se os tamanhos dos contêineres não estiverem configurados corretamente.
• Os requisitos de controle de memória elástica podem afetar negativamente a execução do job.
• Os controles de memória do YARN podem não impedir erros de falta de memória quando os processos consomem memória de forma agressiva.

Proteção de memória do Dataproc

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

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

Papel	1.5	2.0	2.1	2.2
VM principal	1.5.74+	2.0.48+	todas	todas
VM de worker	Não disponível	2.0.76+	2.1.24+	todas
VM do pool de motoristas	Não disponível	2.0.76+	2.1.24+	todas

Use versões de imagem do Dataproc com proteção de memória para evitar erros de falta de memória (OOM) da VM.

Identificar e confirmar encerramentos de proteção de memória

Use as informações a seguir para identificar e confirmar o encerramento de jobs devido à pressão na memória.

Encerramentos de processos

• Os processos encerrados pela proteção de memória do Dataproc saem com o código 137 ou 143.

• Quando o Dataproc encerra um processo devido à pressão na memória, as seguintes ações ou condições podem ocorrer:

  • O Dataproc incrementa a métrica cumulativa dataproc.googleapis.com/node/problem_count e define reason como ProcessKilledDueToMemoryPressure. Consulte Coleta de métricas de recursos do Dataproc.
  • O Dataproc grava um registro google.dataproc.oom-killer com a mensagem: "A process is killed due to memory pressure: process name. Para ver essas mensagens, ative o Logging e use o seguinte filtro de registro:

    resource.type="cloud_dataproc_cluster"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.cluster_uuid="CLUSTER_UUID"
    jsonPayload.message:"A process is killed due to memory pressure:"
    

Encerramentos de jobs do pool de nós mestre ou de driver

• Quando um job de pool de nós mestre ou de driver do Dataproc é encerrado devido à pressão da memória, ele falha com o código de erro Driver received SIGTERM/SIGKILL signal and exited with INT. Para ver essas mensagens, ative o Logging e use o seguinte filtro de registro:

  resource.type="cloud_dataproc_cluster"
  resource.labels.cluster_name="CLUSTER_NAME"
  resource.labels.cluster_uuid="CLUSTER_UUID"
  jsonPayload.message:"Driver received SIGTERM/SIGKILL signal and exited with"
      

  • Verifique o log google.dataproc.oom-killer ou dataproc.googleapis.com/node/problem_count para confirmar se a proteção de memória do Dataproc encerrou o job (consulte Encerramentos de processos).

  Soluções:

  • Se o cluster tiver um pool de drivers, aumente driver-required-memory-mb para o uso real de memória do job.
  • Se o cluster não tiver um pool de drivers, recrie-o, reduzindo o número máximo de jobs simultâneos em execução no cluster.
  • Use um tipo de máquina de nó mestre com mais memória.

Encerramentos de contêineres YARN do nó de trabalho

• O Dataproc grava a seguinte mensagem no gerenciador de recursos do YARN: container id exited with code EXIT_CODE. Para ver essas mensagens, ative o Logging e use o seguinte filtro de registro:

  resource.type="cloud_dataproc_cluster"
  resource.labels.cluster_name="CLUSTER_NAME"
  resource.labels.cluster_uuid="CLUSTER_UUID"
  jsonPayload.message:"container" AND "exited with code" AND "which potentially signifies memory pressure on NODE
  

• Se um contêiner for encerrado com code INT, verifique o registro google.dataproc.oom-killer ou o dataproc.googleapis.com/node/problem_count para confirmar se a proteção de memória do Dataproc encerrou o job (consulte Encerramentos de processos).

  Soluções:

  • Verifique se os tamanhos dos contêineres estão configurados corretamente.
  • Considere diminuir yarn.nodemanager.resource.memory-mb. Essa propriedade controla a quantidade de memória usada para programar contêineres do YARN.
  • Se os contêineres de job falharem constantemente, verifique se a distorção de dados está causando um aumento no uso de contêineres específicos. Se for o caso, faça uma nova partição do job ou aumente o tamanho do worker para atender aos requisitos de memória adicionais.

Ajustar a proteção de memória do Linux no nó mestre (avançado)

Os nós principais do Dataproc usam o utilitário earlyoom para evitar travamentos do sistema liberando memória quando ela está muito baixa. A configuração padrão é adequada para muitas cargas de trabalho. No entanto, talvez seja necessário ajustar a configuração se o nó mestre tiver uma grande quantidade de memória e apresentar consumo rápido de memória.

Em cenários com alta pressão de memória, o sistema pode entrar em um estado de "thrashing", em que passa a maior parte do tempo no gerenciamento de memória e fica sem resposta. Isso pode acontecer tão rápido que o earlyoom não consegue agir com base nas configurações padrão ou antes que a resposta de falta de memória do kernel seja invocada.

Antes de começar

• Essa é uma opção de ajuste avançado. Antes de ajustar as configurações de earlyoom, priorize outras soluções, como usar uma VM principal com mais memória, reduzir a simultaneidade de jobs ou otimizar o uso da memória do job.

Personalizar as configurações do earlyoom

A configuração padrão do earlyoom usa uma quantidade fixa de memória livre como um gatilho. Em máquinas virtuais com uma grande quantidade de RAM, por exemplo, 32GB ou mais, essa quantidade fixa pode representar uma pequena fração da memória total. Isso torna o sistema suscetível a picos repentinos no uso da memória.

Para personalizar as configurações de earlyoom, conecte-se ao nó principal e modifique o arquivo de configuração.

1. Conecte-se ao nó mestre usando SSH.

2. Abra o arquivo de configuração para edição:

   sudo nano /etc/default/earlyoom
   

3. Ajuste o limite mínimo de memória. Localize a linha EARLYOOM_ARGS. A opção -M <kbytes> define a quantidade mínima de memória livre em KiB que earlyoom tenta manter. O valor padrão é -M 65536, que é 64 MiB.

   Considerações sobre ajuste: definir um valor muito alto para -M pode fazer com que o earlyoom encerre processos de maneira mais agressiva. Isso pode afetar os aplicativos mesmo quando ainda há memória suficiente disponível para eles. Monitore o comportamento do sistema depois de fazer mudanças. Ajuste o valor de -M com base no tamanho da instância e na carga de trabalho. Uma diretriz geral é definir -M como um valor que representa 1-5% da memória total do sistema.

   Para um nó principal com memória substancial, aumente esse valor. Por exemplo, para definir o limite como 1 GiB (1048576 KiB), modifique a linha da seguinte forma:

   EARLYOOM_ARGS="-r 15 -M 1048576 -s 1"
   

   Observações:

   • -r: intervalo do relatório de memória em segundos
   • -s: o limite de espaço de troca para acionar earlyoom

4. Reinicie o serviço earlyoom para aplicar as mudanças:

   sudo systemctl restart earlyoom