Résoudre les erreurs de mémoire insuffisante de la VM
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page fournit des informations sur les erreurs de mémoire saturée (OOM, Out Of Memory) des VM Compute Engine sur Dataproc, et explique 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, out-of-memory), 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.
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 agressivement de la mémoire.
Protection de la mémoire Dataproc
Lorsqu'une VM de cluster Dataproc est sous pression de 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.
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 sur la 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 du pool de nœuds 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.
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êts de 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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eThis document details how to troubleshoot and resolve out-of-memory (OOM) errors that can occur in Dataproc on Compute Engine VMs.\u003c/p\u003e\n"],["\u003cp\u003eOOM errors in Dataproc VMs can result in frozen VMs, job failures, and delays in job execution due to node loss on YARN HDFS.\u003c/p\u003e\n"],["\u003cp\u003eDataproc offers memory protection that terminates processes or containers when VMs experience memory pressure, using exit codes 137 or 143 to indicate terminations.\u003c/p\u003e\n"],["\u003cp\u003eJob terminations due to memory pressure can be confirmed by reviewing the \u003ccode\u003egoogle.dataproc.oom-killer\u003c/code\u003e log or checking the \u003ccode\u003edataproc.googleapis.com/node/problem_count\u003c/code\u003e metric.\u003c/p\u003e\n"],["\u003cp\u003eSolutions to memory pressure issues include increasing driver memory, recreating clusters with lower concurrent job limits, or adjusting YARN container memory configurations.\u003c/p\u003e\n"]]],[],null,["This page provides information on Dataproc on\nCompute Engine VM out-of-memory (OOM) errors, and explains steps you can take\nto troubleshoot and resolve OOM errors.\n\nOOM error effects\n\nWhen Dataproc on Compute Engine VMs encounter out-of-memory\n(OOM) errors, the effects include the following conditions:\n\n- Master and worker VMs freeze for a period of time.\n\n- Master VMs OOM errors cause jobs to fail with \"task not acquired\" errors.\n\n- Worker VM OOM errors cause a loss of the node on YARN HDFS, which delays\n Dataproc job execution.\n\nYARN memory controls\n\n[Apache YARN](https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/YARN.html)\nprovides the following types of\n[memory controls](https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/NodeManagerCGroupsMemory.html):\n\n- Polling based (legacy)\n- Strict\n- Elastic\n\nBy default, Dataproc doesn't set\n`yarn.nodemanager.resource.memory.enabled` to enable YARN memory controls, for\nthe following reasons:\n\n- Strict memory control can cause the termination of containers when there is sufficient memory if container sizes aren't configured correctly.\n- Elastic memory control requirements can adversely affect job execution.\n- YARN memory controls can fail to prevent OOM errors when processes aggressively consume memory.\n\nDataproc memory protection\n\nWhen a Dataproc cluster VM is under memory pressure,\nDataproc memory protection terminates processes or containers\nuntil the OOM condition is removed.\n\nDataproc provides memory protection for the following cluster\nnodes in the following\n[Dataproc on Compute Engine image versions](/dataproc/docs/concepts/versioning/dataproc-version-clusters):\n\n| Role | 1.5 | 2.0 | 2.1 | 2.2 |\n|----------------|---------------|---------|---------|-----|\n| Master VM | 1.5.74+ | 2.0.48+ | all | all |\n| Worker VM | Not Available | 2.0.76+ | 2.1.24+ | all |\n| Driver Pool VM | Not Available | 2.0.76+ | 2.1.24+ | all |\n\n| Use Dataproc image versions with memory protection to help avoid VM OOM errors.\n\nIdentify and confirm memory protection terminations\n\nYou can use the following information to identify and confirm\njob terminations due to memory pressure.\n\nProcess terminations\n\n- Processes that Dataproc memory protection terminates exit\n with code `137` or `143`.\n\n- When Dataproc terminates a process due to memory pressure,\n the following actions or conditions can occur:\n\n - Dataproc increments the `dataproc.googleapis.com/node/problem_count` cumulative metric, and sets the `reason` to `ProcessKilledDueToMemoryPressure`. See [Dataproc resource metric collection](/dataproc/docs/guides/dataproc-metrics#dataproc_resource_metric_collection).\n - Dataproc writes a `google.dataproc.oom-killer` log with the message: `\"A process is killed due to memory pressure: `\u003cvar translate=\"no\"\u003eprocess name\u003c/var\u003e. To view these messages, enable Logging, then use the following log filter: \n\n ```\n resource.type=\"cloud_dataproc_cluster\"\n resource.labels.cluster_name=\"CLUSTER_NAME\"\n resource.labels.cluster_uuid=\"CLUSTER_UUID\"\n jsonPayload.message:\"A process is killed due to memory pressure:\"\n ```\n\nMaster node or driver node pool job terminations\n\n- When a Dataproc master node or driver node pool job\n terminates due to memory pressure, the job fails with error\n `Driver received SIGTERM/SIGKILL signal and exited with `\u003cvar translate=\"no\"\u003eINT\u003c/var\u003e\n code. To view these messages, enable Logging, then use the\n following log filter:\n\n ```\n resource.type=\"cloud_dataproc_cluster\"\n resource.labels.cluster_name=\"CLUSTER_NAME\"\n resource.labels.cluster_uuid=\"CLUSTER_UUID\"\n jsonPayload.message:\"Driver received SIGTERM/SIGKILL signal and exited with\"\n \n ```\n\n \u003cbr /\u003e\n\n - Check the `google.dataproc.oom-killer` log or the `dataproc.googleapis.com/node/problem_count` to confirm that Dataproc Memory Protection terminated the job (see [Process terminations](#process_terminations)).\n\n **Solutions:**\n - If the cluster has a [driver pool](/dataproc/docs/guides/node-groups/dataproc-driver-node-groups), increase `driver-required-memory-mb` to actual job memory usage.\n - If the cluster does not have a driver pool, recreate the cluster, lowering the [maximum number of concurrent jobs](/dataproc/docs/concepts/jobs/life-of-a-job#job_concurrency) running on the cluster.\n - Use a master node machine type with increased memory.\n\nWorker node YARN container terminations\n\n- Dataproc writes the following message in the YARN\n resource manager: \u003cvar translate=\"no\"\u003econtainer id\u003c/var\u003e` exited with code\n `\u003cvar translate=\"no\"\u003eEXIT_CODE\u003c/var\u003e. To view these messages, enable\n Logging, then use the following log filter:\n\n ```\n resource.type=\"cloud_dataproc_cluster\"\n resource.labels.cluster_name=\"CLUSTER_NAME\"\n resource.labels.cluster_uuid=\"CLUSTER_UUID\"\n jsonPayload.message:\"container\" AND \"exited with code\" AND \"which potentially signifies memory pressure on NODE\n ```\n- If a container exited with `code `\u003cvar translate=\"no\"\u003eINT\u003c/var\u003e, check the\n `google.dataproc.oom-killer` log or the `dataproc.googleapis.com/node/problem_count`\n to confirm that Dataproc Memory Protection terminated the job\n (see [Process terminations](#process_terminations)).\n\n **Solutions:**\n - Check that container sizes are configured correctly.\n - Consider lowering `yarn.nodemanager.resource.memory-mb`. This property controls the amount of memory used for scheduling YARN containers.\n - If job containers consistently fail, check if data skew is causing increased usage of specific containers. If so, repartition the job or increase worker size to accommodate additional memory requirements."]]
