Fehlerbehebung bei VM-Fehlern aufgrund von fehlendem Arbeitsspeicher

Auf dieser Seite finden Sie Informationen zu OOM-Fehlern (Out-of-Memory-Fehler) bei Compute Engine-VMs mit Managed Service for Apache Spark und Schritte zur Fehlerbehebung und Behebung von OOM-Fehlern.

Auswirkungen von OOM-Fehlern

Wenn bei Managed Service for Apache Spark-VMs OOM-Fehler 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 Fehlern vom Typ „task not acquired“ fehlschlagen.

  • OOM-Fehler bei Worker-VMs führen zu einem Verlust des Knotens in YARN HDFS, wodurch sich die Ausführung von Managed Service for Apache Spark-Jobs verzögert.

YARN-Speichersteuerung

Apache YARN bietet die folgenden Arten der Speichersteuerung:

  • Polling-basiert (Legacy)
  • Strikt
  • Elastisch

Standardmäßig wird in Managed Service for Apache Spark yarn.nodemanager.resource.memory.enabled nicht festgelegt, um die YARN-Speichersteuerung zu aktivieren. Die Gründe dafür sind:

  • Eine strikte Speichersteuerung kann dazu führen, dass Container beendet werden, obwohl genügend Arbeitsspeicher vorhanden ist, wenn die Containergrößen nicht richtig konfiguriert sind.
  • Die Anforderungen an die elastische Speichersteuerung können sich negativ auf die Jobausführung auswirken.
  • Die YARN-Speichersteuerung kann OOM-Fehler möglicherweise nicht verhindern, wenn Prozesse aggressiv Arbeitsspeicher verbrauchen.

Speicherschutz für Managed Service for Apache Spark

Wenn der Arbeitsspeicher einer Managed Service for Apache Spark-Cluster-VM knapp wird, beendet der Speicherschutz von Managed Service for Apache Spark Prozesse oder Container, bis die OOM-Bedingung behoben ist.

Managed Service for Apache Spark bietet Speicherschutz für die folgenden Cluster knoten 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
VM für den Treiberpool Nicht verfügbar 2.0.76+ 2.1.24+ Alle

Beendigungen durch den Speicherschutz identifizieren und bestätigen

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

Prozessbeendigungen

  • Prozesse, die vom 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 Arbeitsspeichermangel beendet, können die folgenden Aktionen oder Bedingungen auftreten:

    • Managed Service for Apache Spark erhöht die kumulative Messwert dataproc.googleapis.com/node/problem_count und setzt reason auf ProcessKilledDueToMemoryPressure. Weitere Informationen finden Sie unter Messwerterhebung für Managed Service for Apache Spark-Ressourcen.
    • 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. Aktivieren Sie Logging, um diese Meldungen aufzurufen, 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:"

Jobbeendigungen für Masterknoten oder Treiberknotenpools

  • Wenn ein Managed Service for Apache Spark-Job für einen Masterknoten oder einen Treiberknotenpool aufgrund von Arbeitsspeichermangel beendet wird, schlägt der Job mit dem Fehler Driver received SIGTERM/SIGKILL signal and exited with INT fehl. Aktivieren Sie Logging, um diese Meldungen aufzurufen, 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 den dataproc.googleapis.com/node/problem_count um zu bestätigen, dass der Job vom Speicherschutz von Managed Service for Apache Spark 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 Maschinentyp für den Masterknoten mit mehr Arbeitsspeicher.

Beendigungen von YARN-Containern für Worker-Knoten

  • Managed Service for Apache Spark schreibt die folgende Meldung in den YARN Ressourcenmanager: container id exited with code EXIT_CODE. Aktivieren Sie Logging, um diese Meldungen aufzurufen, 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 den Messwert dataproc.googleapis.com/node/problem_count um zu bestätigen, dass der Job vom Speicherschutz von Managed Service for Apache Spark beendet wurde (siehe Prozessbeendigungen).

    Lösungen :

    • Prüfen Sie, ob die Containergrößen richtig konfiguriert sind.
    • Erwägen Sie, yarn.nodemanager.resource.memory-mb zu verringern. Mit dieser Eigenschaft wird die Menge an Arbeitsspeicher gesteuert, die für die Planung von YARN-Containern verwendet wird.
    • Wenn Jobcontainer immer wieder fehlschlagen, prüfen Sie, ob eine Datenverzerrung zu einer erhöhten Nutzung bestimmter Container führt. Wenn dies der Fall ist, partitionieren Sie den Job neu oder erhöhen Sie die Workergröße, um den zusätzlichen Arbeitsspeicheranforderungen gerecht zu werden.

Linux-Speicherschutz auf dem Masterknoten optimieren (erweitert)

Managed Service for Apache Spark-Masterknoten verwenden das Dienstprogramm earlyoom, um Systemabstürze zu verhindern, indem Arbeitsspeicher freigegeben wird, wenn der verfügbare Arbeitsspeicher kritisch niedrig ist. Die Standardkonfiguration ist für viele Arbeitslasten geeignet. Möglicherweise müssen Sie die Konfiguration jedoch anpassen, wenn Ihr Masterknoten viel Arbeitsspeicher hat und der Arbeitsspeicher schnell verbraucht wird.

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

Hinweis

  • Dies ist eine erweiterte Optimierungsoption. Bevor Sie die earlyoom-Einstellungen anpassen, sollten Sie andere Lösungen in Betracht ziehen, z. B. eine Master-VM mit mehr Arbeitsspeicher verwenden, die Jobparallelität verringern oder die Arbeitsspeichernutzung des Jobs optimieren.

earlyoom-Einstellungen anpassen

Die Standardkonfiguration von earlyoom verwendet eine feste Menge an kostenlosem Arbeitsspeicher als Trigger. Bei VMs mit viel RAM, z. B. 32GB oder mehr, kann diese feste Menge einen kleinen Teil 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 über SSH eine Verbindung zu Ihrem Masterknoten her.

  2. Öffnen Sie die Konfigurationsdatei zur Bearbeitung:

    sudo nano /etc/default/earlyoom

  3. Passen Sie den Mindestschwellenwert für den Arbeitsspeicher an. Suchen Sie die Zeile EARLYOOM_ARGS. Die -M <kbytes> Option legt die Mindestmenge an kostenlosem Arbeitsspeicher in KiB fest, die earlyoom beizubehalten versucht. Der Standardwert ist -M 65536, was 64 MiB entspricht.

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

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

    Hinweise:

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

  4. Starten Sie den earlyoom-Dienst neu, um die Änderungen anzuwenden:

    sudo systemctl restart earlyoom