Problèmes de mémoire Spark

Lorsque les executors manquent de mémoire, Spark les retire et réessaie ces tâches. Le travail ralentit, et après plusieurs échecs, la phase et le travail échouent.

Utilisez cette page lorsque les travaux échouent ou que les exécuteurs sont supprimés et que le journal des événements du calcul ne montre pas de pertes d’instances Spot ou préemptibles ni de mise à l’échelle automatique. Pour vérifier le journal des événements, voir Tâches défaillantes ou exécuteurs supprimés. Si l’étape se termine mais est lente et affiche un débordement, voir Asymétrie des données et débordement sur disque.

Vérification d’un problème de mémoire

Les problèmes de mémoire provoquent souvent des erreurs telles que :

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.

Ces erreurs sont souvent génériques, et d’autres problèmes peuvent en être la cause. Si vous suspectez un problème de mémoire, vérifiez-le en doublant la mémoire par cœur pour voir si cela résout le problème.

Par exemple, si le type worker dispose de 4 cœurs et 16 Go de mémoire, passez à un type worker avec 4 cœurs et 32 Go de mémoire. Cela vous donne 8 Go par cœur de processeur au lieu de 4 Go. Le ratio mémoire/cœurs compte, pas la mémoire totale. Si le travail met plus de temps à échouer ou n’échoue pas du tout, la mémoire pourrait en être la cause.

Si l’augmentation de la mémoire résout le problème, conservez le type de worker le plus volumineux. Si ce n’est pas le cas, ou si le coût supplémentaire est trop élevé, vérifiez les causes possibles dans la section suivante.

Causes possibles

Les problèmes de mémoire ont de nombreuses causes possibles. Commencez par ces causes courantes :

• Trop peu de partitions de shuffle. Réglez spark.sql.shuffle.partitions sur auto afin que Spark choisisse le nombre de partitions de mélange. Voir configuration AQE.
• Une grande diffusion. Vérifiez les indications de jointure broadcast sur de grandes tables, et examinez le seuil de broadcast à l’exécution. Voir configuration AQE.
• UDFs. Chaque tâche qui exécute une UDF peut charger toutes les données de sa partition en mémoire. Réécrivez la UDF en utilisant des fonctions natives, ou repartitionnez avant de l’appliquer. Voir les UDF lents.
• Une fonction fenêtre sans PARTITION BY. Ajoutez une PARTITION BY clause pour que la fenêtre ne couvre pas tout le jeu de données. Voir l’étape Long Spark avec une seule tâche.
• Asymétrie. Vérifiez l’asymétrie dans les indicateurs récapitulatifs de l’étape. Voir Skew. Pour les jointures, voir Gestion dynamique de la jointure d’asymétrie.
• État de la diffusion. Pour les requêtes qui maintiennent l’état de streaming, utilisez le stockage d’état RocksDB et limitez son usage de mémoire. Consultez l’utilisation de la mémoire Cap RocksDB.