Solucionar errores de VM por falta de memoria

Efectos OOM

Cuando Dataproc en las VM de Compute Engine encuentra errores de memoria insuficiente (OOM), ocurre lo siguiente:

  • Las VMs principales y de trabajador se inmovilizan durante un período.

  • Los errores de OOM de las VMs principales provocan que los trabajos fallen con el error “tarea no adquirida”.

  • Los errores de OOM de la VM de trabajador causan una pérdida del nodo en el HDFS de YARN, lo que retrasa la ejecución del trabajo de Dataproc.

Controles de memoria de hilo

Yarn proporciona tres tipos de controles de memoria:

  1. Basada en encuestas (heredadas)
  2. Estricto
  3. Elastic

De forma predeterminada, Dataproc no configura yarn.nodemanager.resource.memory.enabled para habilitar los controles de memoria de YARN por los siguientes motivos:

  • El control de memoria estricto puede causar la finalización de los contenedores cuando hay suficiente memoria si los tamaños de los contenedores no están configurados de forma correcta.
  • Los requisitos de control de memoria elástica pueden afectar de forma negativa la ejecución del trabajo.
  • Los controles de memoria de YARN pueden fallar para evitar errores de OOM cuando los procesos consumen memoria de forma agresiva.

Protección de memoria de Dataproc

Cuando una VM del clúster de Dataproc está bajo presión de memoria, la protección de memoria de Dataproc finaliza los procesos o contenedores hasta que se quite la condición OOM.

La protección de memoria de Dataproc se proporciona para los siguientes nodos del clúster en las siguientes versiones de imagen de Dataproc en Compute Engine:

Rol 1.5 2.0 2.1
VM principal 1.5.74+ 2.0.48+ todos
VM de trabajador No disponible 2.0.76+ 2.1.24+
VM del grupo de controladores No disponible 2.0.76+ 2.1.24+

Cómo identificar las terminaciones de la protección de memoria de Dataproc

  • Procesa que la protección de memoria de Dataproc termina con el código 137 o 143.
  • Finalización del nodo trabajador:
    • Dataproc incrementa la métrica acumulada de dataproc.googleapis.com/node/problem_count y establece reason en ProcessKilledDueToMemoryPressure.
    • Si Cloud Logging está habilitado, Dataproc escribe un registro google.dataproc.oom-killer con el mensaje “Un proceso se elimina debido a la presión de la memoria: [nombre del proceso]”.
    • Si se finaliza un contenedor YARN, Dataproc escribe el siguiente mensaje en el administrador de recursos de YARN: “[ID del contenedor] salió con el código 137, lo que podría significar una presión de memoria en [ID del nodo]”.
  • Finalización de nodo principal o del grupo de controladores: el controlador del trabajo falla con Driver received SIGTERM/SIGKILL signal and exited with [INT] code.

Soluciones de OOM

En esta sección, se ofrecen recomendaciones para las finalizaciones de trabajos y contenedores que pueden deberse a problemas de OOM.

El trabajo falla y muestra el mensaje “El conductor recibió la señal SIGTERM/SIGKILL y salió con un código [INT]”

Recomendaciones:

  • Si los clústeres tienen un grupo de controladores, aumenta driver-required-memory-mb al uso real de la memoria del trabajo.
  • Si el clúster no tiene un grupo de controladores, vuelve a crearlo y disminuye la cantidad máxima de trabajos simultáneos, que se calcula como (total master memory in MB - 3584MB) / driver-size-mb. Puedes reducir este número de las siguientes maneras:
    • Configurando dataproc:dataproc.scheduler.max-concurrent-jobs.
    • Establecer dataproc:dataproc.scheduler.driver-size-mb en un número mayor (el valor predeterminado es 1024MB).
  • Considera usar un tipo de máquina de nodo principal con memoria adicional.

Contenedor que salió con el código de salida 137 o 143

Recomendaciones:

  • Si la protección de memoria de Dataproc finalizó el contenedor (consulta Cómo identificar las terminaciones de la protección de memoria de Dataproc), haz lo siguiente:

    • Verifica que los tamaños de los contenedores estén configurados de forma correcta.
    • Te recomendamos reducir yarn.nodemanager.resource.memory-mb. Esta propiedad controla la cantidad de memoria que se usa para programar contenedores de YARN.
    • Si los contenedores de trabajos fallan constantemente, verifica si el sesgo de datos está causando un aumento en el uso de contenedores específicos. Si es así, vuelve a particionar el trabajo o aumenta el tamaño del trabajador para que se adapte a requisitos de memoria adicionales.