Spark-Speicherprobleme

Wenn Executors keinen Speicher mehr haben, entfernt Spark sie und führt deren Aufgaben erneut aus. Der Job verlangsamt sich, und nach wiederholten Misserfolgen scheitern Stage und Job.

Nutzen Sie diese Seite, wenn Jobs ausfallen oder Executors entfernt werden und das Ereignisprotokoll des Computes keine Spot- oder Verluste präemptibler Instanzen oder Autoskalierung anzeigt. Um das Ereignisprotokoll zu überprüfen, siehe Fehlgeschlagene Jobs oder entfernte Executoren. Wenn die Stage abschließt, aber langsam ist und Spill zeigt, siehe Skew und Spill.

Überprüfen eines Speicherproblems

Speicherprobleme verursachen oft Fehler wie:

SparkException: Job aborted due to stage failure: Task 3 in stage 0.0 failed 4 times, most recent failure: Lost task 3.3 in stage 0.0 (TID 30) (10.139.64.114 executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages.

Diese Fehler sind oft allgemeiner Natur, und andere Probleme könnten die Ursache dafür sein. Wenn Sie ein Speicherproblem vermuten, überprüfen Sie es, indem Sie den Speicher pro Kern verdoppeln, um zu sehen, ob das Problem dadurch behoben wird.

Wenn zum Beispiel der Worker-Typ 4 Kerne und 16 GB Speicher hat, wechseln Sie zu einem Worker-Typ mit 4 Kernen und 32 GB Speicher. Das gibt 8 GB pro Kern statt 4 GB. Das Verhältnis von Speicher zu Kernen zählt, nicht der gesamte Speicher. Wenn der Job länger braucht, um fehlzuschlagen oder gar nicht scheitert, könnte der Speicher die Ursache sein.

Wenn mehr Speicher das Problem löst, behalte den größeren Worker-Typ. Wenn nicht, oder wenn die zusätzlichen Kosten zu hoch sind, schauen Sie sich die möglichen Ursachen im nächsten Abschnitt an.

Mögliche Ursachen

Gedächtnisprobleme haben viele mögliche Ursachen. Prüfen Sie zunächst diese häufigen Ursachen:

• Zu wenige Shuffle-Partitionen. Setze auto auf spark.sql.shuffle.partitions, damit Spark die Anzahl der Shuffle-Partitionen auswählt. Siehe AQE-Konfiguration.
• Eine große Übertragung. Prüfen Sie große Tabellen auf Broadcast-Join-Hinweise und überprüfen Sie die Laufzeit-Broadcast-Schwelle. Siehe AQE-Konfiguration.
• UDFs. Jede Aufgabe, die eine UDF ausführt, könnte alle Daten ihrer Partition in den Speicher laden. Schreibe das UDF mit nativen Funktionen um oder partitioniere es neu, bevor du es anwendest. Siehe Slow UDFs.
• Eine Window-Funktion ohne PARTITION BY. Fügen Sie eine PARTITION BY Klausel hinzu, damit das Fenster nicht den gesamten Datensatz umfasst. Siehe Long Spark Stage mit einer Aufgabe.
• Verzerren. Überprüfen Sie die Schiefe in den Zusammenfassungskennzahlen der Stufe. Siehe Skew. Für Joins siehe Skew Join dynamisch handhaben.
• Streaming-Zustand. Für Abfragen, die den Streaming-Status beibehalten, verwenden Sie den RocksDB-Zustandsspeicher und begrenzen die Speichernutzung. Siehe Cap RocksDB-Speicherauslastung.