Fehlerbehebung bei VM-Fehlern aufgrund von fehlendem Arbeitsspeicher
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie Informationen zu Fehlern aufgrund fehlenden Speichers (Out-of-Memory, OOM) in Dataproc auf Compute Engine-VMs. Außerdem werden Schritte zur Fehlerbehebung und Behebung von OOM-Fehlern beschrieben.
Auswirkungen von OOM-Fehlern
Wenn auf Dataproc-VMs in Compute Engine Fehler vom Typ „Out of Memory“ (OOM) auftreten, sind die Auswirkungen unter anderem die folgenden:
Master- und Worker-VMs frieren für einen bestimmten Zeitraum ein.
OOM-Fehler bei Master-VMs führen dazu, dass Jobs mit „task not acquired“-Fehlern fehlschlagen.
OOM-Fehler (Out-of-Memory) bei Worker-VMs führen zu einem Verlust des Knotens in YARN HDFS, was die Ausführung von Dataproc-Jobs verzögert.
Standardmäßig wird yarn.nodemanager.resource.memory.enabled in Dataproc nicht festgelegt, um YARN-Speichersteuerungen zu aktivieren. Das hat folgende Gründe:
Eine strenge Arbeitsspeicherverwaltung kann dazu führen, dass Container beendet werden, obwohl ausreichend Arbeitsspeicher vorhanden ist, wenn die Containergrößen nicht richtig konfiguriert sind.
Die Anforderungen für die Steuerung des elastischen Speichers können sich negativ auf die Ausführung von Jobs auswirken.
YARN-Speichersteuerungen können OOM-Fehler nicht verhindern, wenn Prozesse aggressiv Speicher belegen.
Dataproc-Speicherschutz
Wenn eine Dataproc-Cluster-VM unter Speichermangel leidet, beendet der Dataproc-Speicherschutz Prozesse oder Container, bis die OOM-Bedingung behoben ist.
Beendigungen des Speicherschutzes erkennen und bestätigen
Anhand der folgenden Informationen können Sie Jobbeendigungen aufgrund von Speichermangel identifizieren und bestätigen.
Prozessbeendigungen
Prozesse, die durch den Dataproc-Speicherschutz beendet werden, werden mit dem Code 137 oder 143 beendet.
Wenn Dataproc einen Prozess aufgrund von Speicherdruck beendet, können die folgenden Aktionen oder Bedingungen eintreten:
Dataproc erhöht den kumulativen Messwert dataproc.googleapis.com/node/problem_count und setzt reason auf ProcessKilledDueToMemoryPressure.
Weitere Informationen finden Sie unter Erfassung von Messwerten für Dataproc-Ressourcen.
Dataproc schreibt ein google.dataproc.oom-killer-Log mit der Meldung:
"A process is killed due to memory pressure: process name.
Wenn Sie diese Meldungen aufrufen möchten, aktivieren Sie das Logging und verwenden Sie dann den folgenden Logfilter:
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:"
Beenden von Jobs für Master- oder Driver-Knotenpools
Wenn ein Dataproc-Masterknoten oder ein Job im Treiberknotenpool aufgrund von Arbeitsspeicherausfall beendet wird, schlägt der Job mit dem Fehlercode Driver received SIGTERM/SIGKILL signal and exited with INT fehl. Wenn Sie diese Meldungen aufrufen möchten, aktivieren Sie das Logging und verwenden Sie dann den folgenden Logfilter:
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"
Prüfen Sie das google.dataproc.oom-killer-Log oder dataproc.googleapis.com/node/problem_count, um zu bestätigen, dass der Job durch Dataproc Memory Protection beendet wurde (siehe Prozessbeendigungen).
Lösungen:
Wenn der Cluster einen Treiberpool hat, erhöhen Sie driver-required-memory-mb auf die tatsächliche Arbeitsspeichernutzung des Jobs.
Wenn der Cluster keinen Treiberpool hat, erstellen Sie den Cluster neu und verringern Sie die maximale Anzahl gleichzeitiger Jobs, die im Cluster ausgeführt werden.
Verwenden Sie einen Masterknoten-Maschinentyp mit mehr Arbeitsspeicher.
Beenden von YARN-Containern auf Worker-Knoten
Dataproc schreibt die folgende Meldung in den YARN-Ressourcenmanager: container id exited with code
EXIT_CODE. Wenn Sie diese Meldungen aufrufen möchten, aktivieren Sie das Logging und verwenden Sie den folgenden Logfilter:
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
Wenn ein Container mit code INT beendet wurde, prüfen Sie das google.dataproc.oom-killer-Log oder dataproc.googleapis.com/node/problem_count, um zu bestätigen, dass der Job durch Dataproc Memory Protection beendet wurde (siehe Prozessbeendigungen).
Lösungen:
Prüfen Sie, ob die Containergrößen richtig konfiguriert sind.
Sie sollten yarn.nodemanager.resource.memory-mb verringern. Mit dieser Eigenschaft wird die Speichermenge gesteuert, die für die Planung von YARN-Containern verwendet wird.
Wenn Jobcontainer immer wieder fehlschlagen, prüfen Sie, ob die Datenverteilung eine erhöhte Nutzung bestimmter Container verursacht. Wenn ja, partitionieren Sie den Job neu oder erhöhen Sie die Worker-Größe, um den zusätzlichen Arbeitsspeicheranforderungen gerecht zu werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
