Fehlerbehebung bei VM-Fehlern aufgrund von fehlendem Arbeitsspeicher

Auf dieser Seite finden Sie Informationen zu Fehlern aufgrund fehlenden Speichers (Out of Memory, OOM) in Managed Service for Apache Spark auf Compute Engine-VMs. Außerdem werden Schritte zur Fehlerbehebung und Behebung von OOM-Fehlern beschrieben.

Auswirkungen von OOM-Fehlern

Wenn auf Managed Service for Apache Spark-VMs OOM-Fehler (Out-of-Memory) 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 bei Worker-VMs führen zu einem Verlust des Knotens in YARN HDFS, was die Ausführung von Managed Service for Apache Spark-Jobs verzögert.

YARN-Speichersteuerungselemente

Apache YARN bietet die folgenden Arten von Speichersteuerungen:

  • Polling-basiert (alt)
  • Strikt
  • Elastic

Standardmäßig wird yarn.nodemanager.resource.memory.enabled im Managed Service for Apache Spark nicht festgelegt, um die YARN-Speichersteuerung zu aktivieren. Das hat folgende Gründe:

  • Eine strenge Speicherverwaltung kann dazu führen, dass Container beendet werden, obwohl genügend Speicher 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 möglicherweise nicht verhindern, wenn Prozesse aggressiv Speicher belegen.

Speicherschutz für Managed Service for Apache Spark

Wenn eine VM in einem Managed Service for Apache Spark-Cluster unter Speicherdruck steht, beendet der Managed Service for Apache Spark-Speicherschutz Prozesse oder Container, bis die OOM-Bedingung behoben ist.

Managed Service for Apache Spark bietet Speicherschutz für die folgenden Clusterknoten in den folgenden Managed Service for Apache Spark-Imageversionen:

Rolle 1,5 2.0 2.1 2.2
Master-VM 1.5.74+ 2.0.48+ Alle Alle
Worker-VM Nicht verfügbar 2.0.76+ 2.1.24+ Alle
Driver Pool-VM Nicht verfügbar 2.0.76+ 2.1.24+ Alle

Beendigungen des Speicherschutzes erkennen und bestätigen

Anhand der folgenden Informationen können Sie Jobbeendigungen aufgrund von Speichermangel identifizieren und bestätigen.

Kündigungen bearbeiten

  • Prozesse, die durch den Speicherschutz von Managed Service for Apache Spark beendet werden, werden mit dem Code 137 oder 143 beendet.

  • Wenn Managed Service for Apache Spark einen Prozess aufgrund von Speichermangel beendet, können die folgenden Aktionen oder Bedingungen eintreten:

    • Managed Service for Apache Spark erhöht den kumulativen Messwert dataproc.googleapis.com/node/problem_count und legt reason auf ProcessKilledDueToMemoryPressure fest. Weitere Informationen finden Sie unter Erhebung von Ressourcenmesswerten für Managed Service for Apache Spark.
    • Managed Service for Apache Spark 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 Job für einen Masterknoten oder Driver-Knotenpool von Managed Service for Apache Spark aufgrund von Arbeitsspeichermangel 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 die dataproc.googleapis.com/node/problem_count, um zu bestätigen, dass der Job durch den Managed Service for Apache Spark 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

  • Managed Service for Apache Spark 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 dann 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 den Arbeitsspeicherschutz von Managed Service for Apache Spark 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.

Linux-Speicherschutz auf dem Masterknoten optimieren (erweitert)

Auf Masterknoten von Managed Service for Apache Spark wird das Dienstprogramm earlyoom verwendet, um Systemabstürze zu verhindern, indem Arbeitsspeicher freigegeben wird, wenn der verfügbare Arbeitsspeicher kritisch niedrig ist. Die Standardkonfiguration eignet sich für viele Arbeitslasten. Möglicherweise müssen Sie die Konfiguration jedoch anpassen, wenn Ihr Masterknoten über viel Arbeitsspeicher verfügt und der Arbeitsspeicher schnell aufgebraucht wird.

In Szenarien mit hohem Speicherdruck kann das System in einen Zustand des „Thrashing“ eintreten, in dem es die meiste Zeit mit der Speicherverwaltung verbringt und nicht mehr reagiert. Dies kann so schnell geschehen, dass earlyoom nicht auf Grundlage der Standardeinstellungen reagiert oder nicht reagiert, bevor die OOM-Reaktion des Kernels aufgerufen wird.

Hinweis

  • Dies ist eine erweiterte Abstimmungsoption. Bevor Sie die earlyoom-Einstellungen anpassen, sollten Sie andere Lösungen in Betracht ziehen, z. B. die Verwendung einer Master-VM mit mehr Arbeitsspeicher, die Reduzierung der Job-Nebenläufigkeit oder die Optimierung der Job-Arbeitsspeichernutzung.

earlyoom-Einstellungen anpassen

Die Standardkonfiguration von earlyoom verwendet einen festen Betrag an kostenlosem Arbeitsspeicher als Trigger. Auf virtuellen Maschinen mit viel RAM, z. B. 32GB oder mehr, kann dieser feste Betrag einen kleinen Bruchteil des Gesamtspeichers darstellen. Dadurch ist das System anfällig für plötzliche Spitzen bei der Arbeitsspeichernutzung.

Wenn Sie die earlyoom-Einstellungen anpassen möchten, stellen Sie eine Verbindung zum Masterknoten her und ändern Sie die Konfigurationsdatei.

  1. Stellen Sie eine SSH-Verbindung zu Ihrem Masterknoten her.

  2. Öffnen Sie die Konfigurationsdatei zur Bearbeitung:

    sudo nano /etc/default/earlyoom

  3. Mindestspeichergrenzwert anpassen Suchen Sie die Zeile EARLYOOM_ARGS. Mit der Option -M <kbytes> wird die Mindestmenge an kostenlosem Arbeitsspeicher in KiB festgelegt, die earlyoom beibehalten soll. Der Standardwert ist -M 65536, was 64 MiB entspricht.

    Erhöhen Sie diesen Wert für einen Masterknoten mit viel Arbeitsspeicher. Wenn Sie den Grenzwert beispielsweise auf 1 GiB (1048576 KiB) festlegen möchten, ändern Sie die Zeile so:

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

    Hinweise:

    • -r: Intervall für Speicherberichte in Sekunden
    • -s: Der Schwellenwert für den Auslagerungsspeicher, der earlyoom auslöst.

  4. Starten Sie den Dienst earlyoom neu, um die Änderungen zu übernehmen:

    sudo systemctl restart earlyoom