Résoudre les erreurs de mémoire insuffisante de la VM

Cette page fournit des informations sur les erreurs de mémoire saturée (OOM, Out Of Memory) des VM Compute Engine sur Dataproc. Elle explique également les étapes à suivre pour résoudre ces erreurs.

Effets des erreurs OOM

Lorsque les VM Dataproc sur Compute Engine rencontrent des erreurs de mémoire insuffisante (OOM), les effets incluent les conditions suivantes :

  • Les VM maîtres et de nœud de calcul se figent pendant un certain temps.

  • Les erreurs OOM des VM maîtres entraînent l'échec des jobs avec des erreurs "tâche non acquise".

  • Les erreurs OOM des VM de nœud de calcul entraînent la perte du nœud sur YARN HDFS, ce qui retarde l'exécution des jobs Dataproc.

Commandes de mémoire YARN

Apache YARN fournit les types de contrôles de mémoire suivants :

  • Basé sur l'interrogation (ancienne version)
  • Strict
  • Elastic

Par défaut, Dataproc ne définit pas yarn.nodemanager.resource.memory.enabled pour activer les contrôles de mémoire YARN, pour les raisons suivantes :

  • Un contrôle strict de la mémoire peut entraîner l'arrêt des conteneurs lorsqu'il y a suffisamment de mémoire si les tailles des conteneurs ne sont pas configurées correctement.
  • Les exigences de contrôle de la mémoire élastique peuvent nuire à l'exécution des jobs.
  • Les contrôles de mémoire YARN peuvent ne pas empêcher les erreurs de mémoire insuffisante lorsque les processus consomment de la mémoire de manière agressive.

Protection de la mémoire Dataproc

Lorsqu'une VM de cluster Dataproc est sous pression mémoire, la protection de la mémoire Dataproc met fin aux processus ou aux conteneurs jusqu'à ce que la condition OOM soit supprimée.

Dataproc offre une protection de la mémoire pour les nœuds de cluster suivants dans les versions d'image Dataproc sur Compute Engine suivantes :

Rôle 1,5 2.0 2.1 2.2
VM maître 1.5.74+ 2.0.48+ tous tous
VM de nœud de calcul Non disponible 2.0.76+ 2.1.24+ tous
VM du pool de pilotes Non disponible 2.0.76+ 2.1.24+ tous

Identifier et confirmer les terminaisons de protection de la mémoire

Vous pouvez utiliser les informations suivantes pour identifier et confirmer les arrêts de tâches dus à une pression mémoire.

Arrêt des processus

  • Les processus que la protection de la mémoire Dataproc arrête se terminent avec le code 137 ou 143.

  • Lorsque Dataproc met fin à un processus en raison d'une pression de mémoire, les actions ou conditions suivantes peuvent se produire :

    • Dataproc incrémente la métrique cumulative dataproc.googleapis.com/node/problem_count et définit reason sur ProcessKilledDueToMemoryPressure. Consultez la section Collecte des métriques sur les ressources Dataproc.
    • Dataproc écrit un journal google.dataproc.oom-killer avec le message suivant : "A process is killed due to memory pressure: process name. Pour afficher ces messages, activez la journalisation, puis utilisez le filtre de journal suivant : 
      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:"

Arrêt des tâches du pool de nœuds maître ou pilote

  • Lorsqu'un nœud maître ou un pool de nœuds de pilote Dataproc se termine en raison d'une pression sur la mémoire, la tâche échoue avec le code d'erreur Driver received SIGTERM/SIGKILL signal and exited with INT. Pour afficher ces messages, activez la journalisation, puis utilisez le filtre de journal suivant : 

    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"

    • Consultez le journal google.dataproc.oom-killer ou dataproc.googleapis.com/node/problem_count pour confirmer que la protection de la mémoire Dataproc a mis fin au job (voir Arrêts de processus).

    Solutions :

    • Si le cluster dispose d'un pool de pilotes, augmentez driver-required-memory-mb en fonction de l'utilisation réelle de la mémoire du job.
    • Si le cluster ne dispose pas de pool de pilotes, recréez-le en diminuant le nombre maximal de tâches simultanées exécutées sur le cluster.
    • Utilisez un type de machine de nœud maître avec une mémoire accrue.

Arrêts de conteneurs YARN de nœuds de calcul

  • Dataproc écrit le message suivant dans le gestionnaire de ressources YARN : container id exited with code EXIT_CODE. Pour afficher ces messages, activez la journalisation, puis utilisez le filtre de journal suivant :

    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 conteneur s'est arrêté avec le code code INT, consultez le journal google.dataproc.oom-killer ou dataproc.googleapis.com/node/problem_count pour confirmer que la protection de la mémoire Dataproc a mis fin à la tâche (voir Arrêt des processus).

    Solutions :

    • Vérifiez que les tailles des conteneurs sont correctement configurées.
    • Envisagez de baisser yarn.nodemanager.resource.memory-mb. Cette propriété contrôle la quantité de mémoire utilisée pour planifier les conteneurs YARN.
    • Si les conteneurs de tâches échouent systématiquement, vérifiez si l'asymétrie des données entraîne une utilisation accrue de conteneurs spécifiques. Si c'est le cas, repartitionnez le job ou augmentez la taille du nœud de calcul pour répondre aux besoins de mémoire supplémentaires.

Ajuster la protection de la mémoire Linux sur le nœud maître (paramètres avancés)

Les nœuds principaux Dataproc utilisent l'utilitaire earlyoom pour éviter les blocages du système en libérant de la mémoire lorsque la mémoire disponible est extrêmement faible. La configuration par défaut convient à de nombreuses charges de travail. Toutefois, vous devrez peut-être ajuster la configuration si votre nœud maître dispose d'une grande quantité de mémoire et connaît une consommation rapide de mémoire.

Dans les scénarios où la mémoire est fortement sollicitée, le système peut entrer dans un état de "thrashing" (ou "emballement"), où il passe la majeure partie de son temps à gérer la mémoire et devient non réactif. Cela peut se produire si rapidement que earlyoom ne parvient pas à agir en fonction de ses paramètres par défaut ou avant l'invocation de la réponse OOM du noyau.

Avant de commencer

  • Il s'agit d'une option de réglage avancée. Avant d'ajuster les paramètres earlyoom, privilégiez d'autres solutions, comme l'utilisation d'une VM maître avec plus de mémoire, la réduction de la simultanéité des jobs ou l'optimisation de l'utilisation de la mémoire des jobs.

Personnaliser les paramètres earlyoom

La configuration earlyoom par défaut utilise une quantité fixe de mémoire disponible comme déclencheur. Sur les machines virtuelles disposant d'une grande quantité de RAM (par exemple, 32GB ou plus), ce montant fixe peut représenter une petite fraction de la mémoire totale. Le système est donc sensible aux pics soudains d'utilisation de la mémoire.

Pour personnaliser les paramètres earlyoom, connectez-vous au nœud maître et modifiez le fichier de configuration.

  1. Connectez-vous à votre nœud maître à l'aide de SSH.

  2. Ouvrez le fichier de configuration pour le modifier :

    sudo nano /etc/default/earlyoom

  3. Ajustez le seuil de mémoire minimal. Recherchez la ligne EARLYOOM_ARGS. L'option -M <kbytes> définit la quantité minimale de mémoire libre en KiB que earlyoom tente de maintenir. La valeur par défaut est -M 65536, soit 64 MiB.

    Augmentez cette valeur pour un nœud maître disposant d'une mémoire importante. Par exemple, pour définir le seuil sur 1 GiB (1048576 KiB), modifiez la ligne comme suit :

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

    Remarques :

    • -r : intervalle du rapport sur la mémoire en secondes
    • -s : seuil d'espace d'échange pour déclencher earlyoom

  4. Redémarrez le service earlyoom pour appliquer les modifications :

    sudo systemctl restart earlyoom