Problemi di memoria Spark

Quando gli executor esauriscono la memoria, Spark li rimuove e riprova le loro task. Il processo rallenta e, dopo ripetuti errori, la fase e il processo non riescono.

Usa questa pagina quando i job falliscono o gli esecutori vengono rimossi e il registro eventi di Compute non mostra perdite di istanze spot o prerilasciabili o l'autoscaling. Per controllare il registro eventi, vedi Job non riusciti o esecutori rimossi. Se lo stage si completa ma è lento e mostra spill, vedi Skew and spill.

Verifica di un problema di memoria

I problemi di memoria spesso causano errori come:

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.

Questi errori sono spesso generici e altri problemi possono causarli. Se sospetti un problema di memoria, verificalo raddoppiando la memoria per core per vedere se risolve il problema.

Ad esempio, se il tipo worker ha 4 core e 16 GB di memoria, passa a un worker type con 4 core e 32 GB di memoria. Questo ti dà 8 GB per core invece di 4 GB. Il rapporto tra memoria e core conta, non la memoria totale. Se il lavoro impiega più tempo a fallire o non fallisce affatto, la memoria potrebbe essere la causa.

Se più memoria risolve il problema, mantieni il tipo di worker più grande. Se non lo fa, o se il costo extra è troppo alto, controlla le possibili cause nella sezione successiva.

Possibili cause

I problemi di memoria hanno molte possibili cause. Inizia con queste cause comuni:

• Troppe poche partizioni di shuffle. Imposta spark.sql.shuffle.partitions su auto in modo che Spark scelga il numero di partizioni di shuffle. Vedi configurazione AQE.
• Una grande trasmissione. Controlla se ci sono suggerimenti di broadcast join su tabelle grandi e rivedi la soglia di broadcast in fase di esecuzione. Vedi configurazione AQE.
• UDFs. Ogni compito che esegue un UDF può caricare tutti i dati della sua partizione in memoria. Riscrivi l'UDF usando funzioni native, oppure ripartiziona prima di applicarla. Vedi UDF lenti.
• Una window function senza PARTITION BY. Aggiungi una PARTITION BY clausola in modo che la finestra non copra l'intero dataset. Vedi Long Spark stage with one task.
• Inclina. Verifica l'asimmetria nelle Metriche Riassuntive della fase. Vedi Skew. Per i join, vedi Gestire dinamicamente il join sbilanciato.
• Stato di streaming. Per le query che mantengono lo stato di streaming, usa l'archivio dello stato RocksDB e limita l'uso di memoria. Vedere Utilizzo della memoria cap RocksDB.