Resolva problemas de erros de falta de memória da VM

Esta página fornece informações sobre erros de memória insuficiente (OOM) do Dataproc na VM do Compute Engine e explica os passos que pode seguir para resolver problemas de OOM.

Efeitos dos erros de OOM

Quando o Dataproc em VMs do Compute Engine encontra erros de falta de memória (OOM), os efeitos incluem as seguintes condições:

  • As VMs principais e de trabalho ficam bloqueadas durante um período.

  • Os erros de falta de memória (OOM) das VMs principais fazem com que as tarefas falhem com erros "task not acquired" (tarefa não adquirida).

  • Os erros de falta de memória (OOM) da VM do trabalhador causam uma perda do nó no HDFS do YARN, o que atrasa a execução da tarefa do Dataproc.

Controlos de memória do YARN

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

  • Com base em sondagens (antigo)
  • Rigoroso
  • Elastic

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

  • O controlo rigoroso da memória pode causar a terminação de contentores quando existe memória suficiente se os tamanhos dos contentores não estiverem configurados corretamente.
  • Os requisitos de controlo de memória elástica podem afetar negativamente a execução de tarefas.
  • Os controlos 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 termina os processos ou os contentores 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 do cluster nas seguintes versões de imagens do Dataproc no Compute Engine:

Função 1,5 2,0 2.1 2.2
VM principal 1.5.74+ 2.0.48+ todos todos
VM trabalhadora Não disponível 2.0.76+ 2.1.24+ todos
VM do conjunto de controladores Não disponível 2.0.76+ 2.1.24+ todos

Identifique e confirme as terminações da proteção de memória

Pode usar as seguintes informações para identificar e confirmar terminações de tarefas devido à pressão da memória.

Encerramentos de processos

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

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

    • O Dataproc incrementa a métrica cumulativa dataproc.googleapis.com/node/problem_count e define reason como ProcessKilledDueToMemoryPressure. Consulte o artigo Recolha de métricas de recursos do Dataproc.
    • O Dataproc escreve um registo google.dataproc.oom-killer com a mensagem: "A process is killed due to memory pressure: process name. Para ver estas mensagens, ative o Registo e, em seguida, use o seguinte filtro de registo: 
      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 tarefas de node pool de nó principal ou de controlador

  • Quando uma tarefa de pool de nós de controlador ou nó principal do Dataproc termina devido à pressão de memória, a tarefa falha com o código de erro Driver received SIGTERM/SIGKILL signal and exited with INT. Para ver estas mensagens, ative o Registo e, em seguida, use o seguinte filtro de registo: 

    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 registo google.dataproc.oom-killer ou o dataproc.googleapis.com/node/problem_count para confirmar que a proteção de memória do Dataproc terminou a tarefa (consulte Terminações de processos).

    Soluções:

    • Se o cluster tiver um conjunto de controladores, aumente driver-required-memory-mb para a utilização de memória real da tarefa.
    • Se o cluster não tiver um conjunto de controladores, recrie o cluster, reduzindo o número máximo de tarefas simultâneas em execução no cluster.
    • Use um tipo de máquina de nó principal com memória aumentada.

Encerramentos de contentores YARN de nós trabalhadores

  • O Dataproc escreve a seguinte mensagem no gestor de recursos do YARN: container id exited with code EXIT_CODE. Para ver estas mensagens, ative o registo e, de seguida, use o seguinte filtro de registo:

    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 contentor tiver sido terminado com code INT, verifique o registo google.dataproc.oom-killer ou o dataproc.googleapis.com/node/problem_count para confirmar que a proteção de memória do Dataproc terminou a tarefa (consulte Terminações de processos).

    Soluções:

    • Verifique se os tamanhos dos contentores estão configurados corretamente.
    • Considere baixar yarn.nodemanager.resource.memory-mb. Esta propriedade controla a quantidade de memória usada para agendar contentores YARN.
    • Se os contentores de tarefas falharem consistentemente, verifique se a distorção de dados está a causar um aumento da utilização de contentores específicos. Se for o caso, reparticione a tarefa ou aumente o tamanho do trabalhador para satisfazer os requisitos de memória adicionais.

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

Os nós principais do Dataproc usam o utilitário earlyoom para evitar bloqueios do sistema libertando memória quando a memória disponível está criticamente baixa. A configuração predefinida é adequada para muitas cargas de trabalho. No entanto, pode ter de ajustar a configuração se o nó principal tiver uma grande quantidade de memória e registar um consumo rápido de memória.

Em cenários com elevada pressão de memória, o sistema pode entrar num estado de "thrashing", em que passa a maior parte do tempo na gestão de memória e deixa de responder. Isto pode acontecer tão rapidamente que o earlyoom não consegue tomar medidas com base nas respetivas definições predefinidas ou não consegue agir antes de a resposta OOM do kernel ser invocada.

Antes de começar

  • Esta é uma opção de ajuste avançada. Antes de ajustar as earlyoomdefinições, priorize outras soluções, como usar uma VM principal com mais memória, reduzir a concorrência de tarefas ou otimizar a utilização de memória das tarefas.

Personalize as definições de earlyoom

A configuração earlyoom predefinida usa uma quantidade fixa de memória livre como um acionador. Em máquinas virtuais com uma grande quantidade de RAM, por exemplo, 32GB ou mais, esta quantidade fixa pode representar uma pequena fração da memória total. Isto torna o sistema suscetível a picos súbitos na utilização de memória.

Para personalizar as definições de earlyoom, faça a ligação ao nó principal e modifique o ficheiro de configuração.

  1. Estabeleça ligação ao nó principal através do SSH.

  2. Abra o ficheiro 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 o earlyoom tenta manter. O valor predefinido é -M 65536, que é 64 MiB.

    Para um nó principal com memória substancial, aumente este 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"

    Notas:

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

  4. Reinicie o serviço earlyoom para aplicar as alterações:

    sudo systemctl restart earlyoom