Jakie są prawdopodobne przyczyny org.apache.spark.shuffle.MetadataFetchFailedException: Brakuje lokalizacji wyjściowej do przetasowania?

Question

Wdrażam zadanie przetwarzania danych Spark w klastrze EC2, zadanie jest małe dla klastra (16 rdzeni z łącznie 120 G RAM), największy RDD ma tylko 76k + wierszy. Ale mocno przekrzywiony w środku (wymaga to ponownego dzielenia na partycje), a każdy wiersz ma około 100k danych po serializacji. Praca zawsze utknęła w dzieleniu na partycje. Mianowicie, zadanie będzie stale się następujące błędy i ponownych prób:

org.apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 

org.apache.spark.shuffle.FetchFailedException: Error in opening FileSegmentManagedBuffer 

org.apache.spark.shuffle.FetchFailedException: java.io.FileNotFoundException: /tmp/spark-... 

Próbowałem zidentyfikować problem, ale wydaje się, że zarówno w pamięci i na dysku zużycia maszyny rzucanie błędy te są poniżej 50%. Próbowałem także różnych konfiguracji, w tym:

let driver/executor memory use 60% of total memory. 
let netty to priortize JVM shuffling buffer. 
increase shuffling streaming buffer to 128m. 
use KryoSerializer and max out all buffers 
increase shuffling memoryFraction to 0.4 

Ale żaden z nich nie działa. Małe zadanie zawsze wywołuje tę samą serię błędów i maksymalne ponowne próby (do 1000 razy). Jak rozwiązać ten problem w takiej sytuacji?

Wielkie dzięki, jeśli masz jakąkolwiek wskazówkę.

Answer 1

Sprawdź swój log, jeśli pojawi się błąd podobny do tego.

ERROR 2015-05-12 17:29:16,984 Logging.scala:75 - Lost executor 13 on node-xzy: remote Akka client disassociated 

Za każdym razem, gdy pojawia się ten błąd, powoduje to utratę executora. Jako dlaczego straciłeś wykonawcę, to jest inna historia, ponownie sprawdź swój dziennik pod kątem wskazówek.

Jedno Nitki mogą zabić swoją pracę, jeśli uzna, że ​​widzieć używasz „zbyt dużo pamięci”

Sprawdzić coś takiego:

org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl - Container [<edited>] is running beyond physical memory limits. Current usage: 18.0 GB of 18 GB physical memory used; 19.4 GB of 37.8 GB virtual memory used. Killing container. 

Zobacz także: http://apache-spark-developers-list.1001551.n3.nabble.com/Lost-executor-on-YARN-ALS-iterations-td7916.html

Obecny stan techniki polega na zwiększeniu wartości spark.yarn.executor.memoryOverhead, dopóki zadanie nie przestanie działać. Mamy plany, aby spróbować automatycznie skalować je na podstawie żądanej ilości pamięci, ale nadal będzie to po prostu heurystyka.

Answer 2

Byłem też coraz error

org.apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 

i szuka dalej w dzienniku znalazłem

Container killed on request. Exit code is 143 

Po wyszukaniu kodu wyjścia, zdałem sobie sprawę, że to jego głównie związane z alokacją pamięci. Sprawdziłem więc ilość pamięci, którą skonfigurowałem dla executorów. Stwierdziłem, że przez pomyłkę skonfigurowałem 7g dla sterownika i tylko 1g dla executora. Po zwiększeniu pamięci executora moje zadanie iskrzenia przebiegło pomyślnie.