"Managed Service for Apache Spark" is the new name for the product formerly known as "Dataproc on Compute Engine" (cluster deployment) and "Google Cloud Serverless for Apache Spark" (serverless deployment).

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Soluciona problemas de errores de memoria insuficiente de la VM

En esta página, se proporciona información sobre los errores de falta de memoria (OOM) del servicio administrado para Apache Spark en las VMs de Compute Engine y se explican los pasos que puedes seguir para solucionar y resolver estos errores.

Efectos de los errores de OOM

Cuando las VMs de Managed Service para Apache Spark encuentran errores de memoria insuficiente (OOM), los efectos incluyen las siguientes condiciones:

Las VMs principales y de trabajador se congelan durante un período.
Los errores de OOM de las VMs principales provocan que los trabajos fallen con errores de "tarea no adquirida".
Los errores de OOM de la VM del trabajador provocan la pérdida del nodo en YARN HDFS, lo que retrasa la ejecución del trabajo de Managed Service para Apache Spark.

Controles de memoria de YARN

Apache YARN proporciona los siguientes tipos de controles de memoria:

Basado en sondeos (heredado)
Estricto
Elastic

De forma predeterminada, Managed Service para Apache Spark no establece yarn.nodemanager.resource.memory.enabled para habilitar los controles de memoria de YARN por los siguientes motivos:

El control estricto de la memoria puede provocar la finalización de los contenedores cuando hay suficiente memoria si los tamaños de los contenedores no están configurados correctamente.
Los requisitos de control de memoria elástica pueden afectar de forma adversa la ejecución de trabajos.
Los controles de memoria de YARN pueden fallar y no evitar los errores de OOM cuando los procesos consumen memoria de forma agresiva.

Protección de memoria de Managed Service para Apache Spark

Cuando la VM de un clúster de Managed Service para Apache Spark está bajo presión de memoria, la protección de memoria de Managed Service para Apache Spark finaliza los procesos o contenedores hasta que se quita la condición de OOM.

Managed Service para Apache Spark proporciona protección de memoria para los siguientes nodos de clúster en las siguientes versiones de imágenes de Managed Service para Apache Spark:

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

Identifica y confirma 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 memoria.

Finalizaciones de procesos

Los procesos que finaliza la protección de memoria de Managed Service para Apache Spark salen con el código 137 o 143.
Cuando Managed Service para Apache Spark finaliza un proceso debido a la presión de la memoria, pueden ocurrir las siguientes acciones o condiciones:
- Managed Service para Apache Spark incrementa la métrica acumulativa dataproc.googleapis.com/node/problem_count y establece reason en ProcessKilledDueToMemoryPressure. Consulta la recopilación de métricas de recursos de Managed Service para Apache Spark.
- Managed Service para Apache Spark 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, luego, 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 trabajos de grupos de nodos controladores o nodos principales

Cuando un trabajo de grupo de nodos controladores o nodos principales de Managed Service para Apache Spark finaliza debido a la presión de la memoria, el trabajo falla con el código de error Driver received SIGTERM/SIGKILL signal and exited with INT. Para ver estos mensajes, habilita el registro y, luego, 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"
    
```
- Verifica el registro google.dataproc.oom-killer o el dataproc.googleapis.com/node/problem_count para confirmar que la Protección de memoria de Managed Service para Apache Spark finalizó el trabajo (consulta Finalizaciones de procesos).
Soluciones:
- Si el clúster tiene un grupo de controladores, aumenta driver-required-memory-mb al uso real de memoria del trabajo.
- Si el clúster no tiene un grupo de controladores, vuelve a crearlo y reduce la cantidad máxima de trabajos simultáneos que se ejecutan en él.
- Usa un tipo de máquina de nodo principal con mayor memoria.

Finalizaciones de contenedores YARN de nodos trabajadores

Managed Service para Apache Spark escribe el siguiente mensaje en el administrador de recursos de YARN: container id exited with code EXIT_CODE. Para ver estos mensajes, habilita el registro y, luego, 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 salió 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 Managed Service para Apache Spark finalizó el trabajo (consulta Finalizaciones de procesos).

Soluciones:
- Verifica que los tamaños de los contenedores estén configurados correctamente.
- Considera 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 de forma constante, verifica 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 satisfacer los requisitos de memoria adicionales.

Ajusta la protección de memoria de Linux en el nodo principal (avanzado)

Los nodos principales de Managed Service para Apache Spark usan la utilidad earlyoom para evitar que el sistema se bloquee, ya que liberan memoria cuando esta es muy baja. La configuración predeterminada es adecuada para muchas cargas de trabajo. Sin embargo, es posible que debas ajustar la configuración si tu nodo principal tiene una gran cantidad de memoria y experimenta un consumo rápido de memoria.

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

Antes de comenzar

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

Personaliza la configuración de `earlyoom`

La configuración predeterminada de earlyoom 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 podría representar una pequeña fracción de la memoria total. Esto hace que el sistema sea susceptible a aumentos repentinos en el uso de memoria.

Para personalizar la configuración de earlyoom, conéctate al nodo principal y modifica el archivo de configuración.

Conéctate a tu nodo principal con SSH.
Abre el archivo de configuración para editarlo:
```
sudo nano /etc/default/earlyoom
```
Ajusta el umbral de memoria mínimo. Ubica la línea EARLYOOM_ARGS. La opción -M <kbytes> establece la cantidad mínima de memoria libre en KiB que earlyoom intenta mantener. El valor predeterminado es -M 65536, que es 64 MiB.

Consideraciones sobre el ajuste: Si se establece un valor demasiado alto para -M, es posible que earlyoom finalice los procesos de forma más agresiva. Esto puede afectar a las aplicaciones incluso cuando aún haya suficiente memoria disponible para ellas. Supervisa el comportamiento del sistema después de realizar cambios. Ajusta el valor de -M según el tamaño de tu instancia y la carga de trabajo. Un lineamiento general es establecer -M en un valor que represente 1-5% de la memoria total del sistema.

Para un nodo principal con una cantidad considerable de memoria, aumenta este valor. Por ejemplo, para establecer 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: Es el límite de espacio de intercambio para activar earlyoom.
Reinicia el servicio de earlyoom para aplicar los cambios:
```
sudo systemctl restart earlyoom
```