Resolver erros de falta de memória da VM

Esta página fornece 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 você pode seguir para solucionar e resolver erros de OOM.

Efeitos de erros de OOM

Quando as VMs do Serviço Gerenciado para Apache Spark encontram erros de falta de memória (OOM), os efeitos incluem as seguintes condições:

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

  • Os erros de OOM das VMs mestre fazem com que os jobs falhem com erros de "tarefa não adquirida".

  • Os erros de OOM 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
  • Elástico

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 de memória estrito 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 falhar ao impedir erros de OOM 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 OOM 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 mestre 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 drivers Não disponível 2.0.76+ 2.1.24+ todas

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

Você pode usar as informações a seguir para identificar e confirmar os encerramentos de jobs devido à pressão de memória.

Encerramentos de processos

  • Os processos que a proteção de memória do Serviço Gerenciado para Apache Spark encerra 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 o reason como ProcessKilledDueToMemoryPressure. Consulte a 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 conferir essas mensagens, ative o Cloud 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 de driver

  • Quando um job do nó mestre ou do pool de nós de driver do Serviço Gerenciado para Apache Spark é encerrado devido à pressão de memória, o job falha com o erro Driver received SIGTERM/SIGKILL signal and exited with INT código. Para conferir essas mensagens, ative o Cloud 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 google.dataproc.oom-killer registro 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 da memória real do job.
    • Se o cluster não tiver um pool de drivers, recrie o cluster, diminuindo 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 conferir essas mensagens, ative o Cloud 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 foi encerrado com code INT, verifique o google.dataproc.oom-killer registro 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 YARN.
    • Se os contêineres de job falharem de forma consistente, verifique se a distorção de dados está causando um aumento no uso de contêineres específicos. Se for o caso, reparticione o job ou aumente o tamanho do worker para acomodar requisitos de memória adicionais.

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

Os nós mestre do Serviço Gerenciado para Apache Spark usam o utilitário earlyoom para evitar travamentos do sistema, liberando memória quando a memória disponível está criticamente 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 gasta a maior parte do tempo no gerenciamento de memória e fica sem resposta. Isso pode acontecer tão rapidamente que earlyoom não consegue agir com base nas configurações padrão ou não consegue agir antes que a resposta OOM do kernel seja invocada.

Antes de começar

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

Personalizar as configurações de earlyoom

A configuração padrão de 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ó mestre 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 -M <kbytes> opção 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ó mestre com memória substancial, aumente esse valor. Por exemplo, para definir o limite como 1 GiB (1048576 KiB), modifique a linha da seguinte maneira:

    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 alterações:

    sudo systemctl restart earlyoom