Resolver erros de falta de memória da VM

Nesta página, você encontra informações sobre erros de falta de memória (OOM, na sigla em inglês) do Serviço Gerenciado para Apache Spark 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 Serviço Gerenciado para Apache Spark 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 de worker causam uma perda do nó no YARN HDFS, o que atrasa a execução do job do Serviço Gerenciado para Apache Spark.

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 Serviço Gerenciado para Apache Spark 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 evitar erros de falta de memória quando os processos consomem memória de forma agressiva.

Proteção de memória do Serviço Gerenciado para Apache Spark

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

O Serviço Gerenciado para Apache Spark oferece proteção de memória para os seguintes nós de cluster nas seguintes versões de imagem do Serviço Gerenciado para Apache Spark:

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

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 Serviço Gerenciado para Apache Spark saem com o código 137 ou 143.

  • Quando o Serviço Gerenciado para Apache Spark encerra um processo devido à pressão de memória, as seguintes ações ou condições podem ocorrer:

    • O Serviço Gerenciado para Apache Spark incrementa a métrica cumulativa dataproc.googleapis.com/node/problem_count e define reason como ProcessKilledDueToMemoryPressure. Consulte Coleta de métricas de recursos do Serviço Gerenciado para Apache Spark.
    • O Serviço Gerenciado para Apache Spark 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 nó mestre ou do pool de nós do driver

  • Quando um job do pool de nós do driver ou do nó principal do Serviço Gerenciado para Apache Spark é encerrado devido à pressão de 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 registro de google.dataproc.oom-killer ou o dataproc.googleapis.com/node/problem_count para confirmar se a proteção de memória do Serviço Gerenciado para Apache Spark 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 de nós de trabalho

  • O Serviço Gerenciado para Apache Spark 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 Serviço Gerenciado para Apache Spark 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 Serviço gerenciado para Apache Spark 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ó principal 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.

    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