Solucionar errores de falta de memoria de las máquinas virtuales

En esta página se proporciona información sobre los errores de falta de memoria (OOM) de las VMs de Dataproc en Compute Engine y se explican los pasos que puede seguir para solucionar estos errores.

Efectos de errores de falta de memoria

Cuando las VMs de Dataproc en Compute Engine se quedan sin memoria (OOM), se producen las siguientes situaciones:

  • Las VMs maestras y de trabajador se congelan durante un periodo.

  • Los errores de falta de memoria (OOM) de las VMs maestras provocan que los trabajos fallen y se muestren errores de "tarea no adquirida".

  • Los errores de falta de memoria de las VMs de trabajador provocan la pérdida del nodo en YARN HDFS, lo que retrasa la ejecución de los trabajos de Dataproc.

Controles de memoria de YARN

Apache YARN proporciona los siguientes tipos de controles de memoria:

  • Basada en sondeos (versión antigua)
  • Estricto
  • Elastic

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

  • Un control estricto de la memoria puede provocar la finalización de los contenedores cuando haya suficiente memoria si los tamaños de los contenedores no están configurados correctamente.
  • Los requisitos de control de memoria elástica pueden afectar negativamente a la ejecución de los trabajos.
  • Los controles de memoria de YARN pueden no evitar los errores de falta de memoria cuando los procesos consumen memoria de forma agresiva.

Protección de memoria de Dataproc

Cuando una VM de un clúster de Dataproc tiene problemas de memoria, la protección de memoria de Dataproc finaliza los procesos o los contenedores hasta que se elimina la condición de falta de memoria.

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

Rol 1,5 2,0 2.1 2.2
VM maestra 1.5.74+ 2.0.48+ todos todos
VM de trabajador No disponible 2.0.76+ 2.1.24+ todos
VM de Driver Pool No disponible 2.0.76+ 2.1.24+ todos

Identificar y confirmar las finalizaciones de la protección de memoria

Puedes usar la siguiente información para identificar y confirmar las finalizaciones de trabajos debido a la presión de la memoria.

Procesar finalizaciones

  • Los procesos que finaliza la protección de memoria de Dataproc salen con el código 137 o 143.

  • Cuando Dataproc finaliza un proceso debido a la presión de memoria, pueden producirse las siguientes acciones o condiciones:

    • Dataproc incrementa la métrica acumulativa dataproc.googleapis.com/node/problem_count y asigna el valor reason a ProcessKilledDueToMemoryPressure. Consulta Recogida de métricas de recursos de Dataproc.
    • Dataproc escribe un registro google.dataproc.oom-killer con el mensaje: "A process is killed due to memory pressure: process name. Para ver estos mensajes, habilita el registro y, a continuación, usa el siguiente 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:"

Finalizaciones de tareas de grupos de nodos maestros o de controladores

  • Cuando una tarea de un nodo maestro o de un grupo de nodos de controlador de Dataproc finaliza debido a la presión de la memoria, la tarea falla con el código de error Driver received SIGTERM/SIGKILL signal and exited with INT. Para ver estos mensajes, habilita el registro y, a continuación, usa el siguiente 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"

    • Consulta el registro google.dataproc.oom-killer o el dataproc.googleapis.com/node/problem_count para confirmar que la protección de memoria de Dataproc ha finalizado el trabajo (consulta Finalizaciones de procesos).

    Soluciones:

    • Si el clúster tiene un grupo de controladores, aumenta driver-required-memory-mb hasta el uso real de memoria del trabajo.
    • Si el clúster no tiene un grupo de controladores, vuelve a crearlo y reduce el número máximo de trabajos simultáneos que se ejecutan en el clúster.
    • Usa un tipo de máquina de nodo maestro con más memoria.

Finalizaciones de contenedores YARN de nodos de trabajador

  • Dataproc escribe el siguiente mensaje en el gestor de recursos de YARN: container id exited with code EXIT_CODE. Para ver estos mensajes, habilita el registro y, a continuación, usa el siguiente 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

  • Si un contenedor ha finalizado con code INT, consulta el registro de google.dataproc.oom-killer o el de dataproc.googleapis.com/node/problem_count para confirmar que la protección de memoria de Dataproc ha finalizado la tarea (consulta Finalizaciones de procesos).

    Soluciones:

    • Comprueba que los tamaños de los contenedores estén configurados correctamente.
    • Te recomendamos que bajes 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 de forma constante, comprueba si la asimetría de datos está provocando un mayor uso de contenedores específicos. Si es así, vuelve a particionar el trabajo o aumenta el tamaño del trabajador para adaptarlo a los requisitos de memoria adicionales.

Ajustar la protección de memoria de Linux en el nodo maestro (avanzado)

Los nodos maestros de Dataproc usan la utilidad earlyoom para evitar que el sistema se bloquee liberando memoria cuando la memoria disponible es muy baja. La configuración predeterminada es adecuada para muchas cargas de trabajo. Sin embargo, es posible que tengas que ajustar la configuración si tu nodo maestro tiene una gran cantidad de memoria y experimenta un consumo rápido de memoria.

En situaciones con mucha presión de memoria, el sistema puede entrar en un estado de "thrashing", en el que dedica la mayor parte del tiempo a la gestión de la memoria y deja de responder. Esto puede ocurrir tan rápido que earlyoom no pueda tomar medidas según su configuración predeterminada o no pueda actuar antes de que se invoque la respuesta OOM del kernel.

Antes de empezar

  • Esta es una opción de ajuste avanzada. Antes de ajustar la configuración de earlyoom, prioriza otras soluciones, como usar una VM maestra con más memoria, reducir la simultaneidad de los trabajos u optimizar el uso de la memoria de los trabajos.

Personalizar los ajustes de earlyoom

La configuración earlyoom predeterminada usa una cantidad fija de memoria libre como activador. En las máquinas virtuales con una gran cantidad de RAM, por ejemplo, 32GB o más, esta cantidad fija puede representar una pequeña parte de la memoria total. Esto hace que el sistema sea susceptible a picos repentinos en el uso de memoria.

Para personalizar los ajustes de earlyoom, conéctate al nodo maestro y modifica el archivo de configuración.

  1. Conéctate al nodo maestro mediante SSH.

  2. Abre el archivo de configuración para editarlo:

    sudo nano /etc/default/earlyoom

  3. Ajusta el umbral de memoria mínimo. Busca la línea EARLYOOM_ARGS. La opción -M <kbytes> define la cantidad mínima de memoria libre en KiB que earlyoom intenta mantener. El valor predeterminado es -M 65536, que es 64 MiB.

    En el caso de un nodo maestro con una cantidad de memoria considerable, aumenta este valor. Por ejemplo, para definir el umbral en 1 GiB (1048576 KiB), modifica la línea de la siguiente manera:

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

    Notas:

    • -r: intervalo del informe de memoria en segundos
    • -s: umbral del espacio de intercambio para activar earlyoom

  4. Reinicia el servicio earlyoom para aplicar los cambios:

    sudo systemctl restart earlyoom