Spark - Container läuft jenseits der physischen Speichergrenzen

Question

Ich habe einen Cluster von zwei Arbeiterknoten. Worker_Node_1 - 64GB RAM Worker_Node_2 - 32 GB RAM

Hintergrund Zusammenfassung: Ich versuche, funkt einreichen auf Garn-Cluster auszuführen Pregel auf einem Diagramm ausführen, um die kürzesten Wegstrecken aus einer Hand Scheitelpunkt, um alle zu berechnen andere Vertices und drucken Sie die Werte auf der Konsole. Experimentierplatte:

1. für kleine Grafik mit 15 Eckpunkten Abschluss der Ausführung Anwendung endgültigen Status: SUCCEEDED
2. Mein Code funktioniert perfekt und Druck kürzeste Entfernung für 241 Eckpunkten Diagramm für einzelne Vertex als Quelle Vertex, aber es ist ein Problem.

Problem: Wenn ich graben sich in das Protokoll die Aufgabe Datei wird komplett erfolgreich in 4 Minuten und 26 Sek aber immer noch auf dem Terminal auf zeigt Anwendungsstatus hält als Laufen und nach ca. 12 mehr Minuten Aufgabenausführung beendet sagen -

Application application_1447669815913_0002 failed 2 times due to AM Container for appattempt_1447669815913_0002_000002 exited with exitCode: -104 For more detailed output, check application tracking page:http://myserver.com:8088/proxy/application_1447669815913_0002/ 
Then, click on links to logs of each attempt. 
Diagnostics: Container [pid=47384,containerID=container_1447669815913_0002_02_000001] is running beyond physical memory limits. Current usage: 17.9 GB of 17.5 GB physical memory used; 18.7 GB of 36.8 GB virtual memory used. Killing container. 

Dump of the process-tree for container_1447669815913_0002_02_000001 : 
|- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE 
|- 47387 47384 47384 47384 (java) 100525 13746 20105633792 4682973 /usr/lib/jvm/java-7-oracle-cloudera/bin/java -server -Xmx16384m -Djava.io.tmpdir=/yarn/nm/usercache/cloudera/appcache/application_1447669815913_0002/container_1447669815913_0002_02_000001/tmp -Dspark.eventLog.enabled=true -Dspark.eventLog.dir=hdfs://myserver.com:8020/user/spark/applicationHistory -Dspark.executor.memory=14g -Dspark.shuffle.service.enabled=false -Dspark.yarn.executor.memoryOverhead=2048 -Dspark.yarn.historyServer.address=http://myserver.com:18088 -Dspark.driver.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native -Dspark.shuffle.service.port=7337 -Dspark.yarn.jar=local:/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/spark/lib/spark-assembly.jar -Dspark.serializer=org.apache.spark.serializer.KryoSerializer -Dspark.authenticate=false -Dspark.app.name=com.path.PathFinder -Dspark.master=yarn-cluster -Dspark.executor.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native -Dspark.yarn.am.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native -Dspark.yarn.app.container.log.dir=/var/log/hadoop-yarn/container/application_1447669815913_0002/container_1447669815913_0002_02_000001 org.apache.spark.deploy.yarn.ApplicationMaster --class com.path.PathFinder --jar file:/home/cloudera/Documents/Longest_Path_Data_1/Jars/ShortestPath_Loop-1.0.jar --arg /home/cloudera/workspace/Spark-Integration/LongestWorstPath/configFile --executor-memory 14336m --executor-cores 32 --num-executors 2 
|- 47384 47382 47384 47384 (bash) 2 0 17379328 853 /bin/bash -c LD_LIBRARY_PATH=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native::/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native /usr/lib/jvm/java-7-oracle-cloudera/bin/java -server -Xmx16384m -Djava.io.tmpdir=/yarn/nm/usercache/cloudera/appcache/application_1447669815913_0002/container_1447669815913_0002_02_000001/tmp '-Dspark.eventLog.enabled=true' '-Dspark.eventLog.dir=hdfs://myserver.com:8020/user/spark/applicationHistory' '-Dspark.executor.memory=14g' '-Dspark.shuffle.service.enabled=false' '-Dspark.yarn.executor.memoryOverhead=2048' '-Dspark.yarn.historyServer.address=http://myserver.com:18088' '-Dspark.driver.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native' '-Dspark.shuffle.service.port=7337' '-Dspark.yarn.jar=local:/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/spark/lib/spark-assembly.jar' '-Dspark.serializer=org.apache.spark.serializer.KryoSerializer' '-Dspark.authenticate=false' '-Dspark.app.name=com.path.PathFinder' '-Dspark.master=yarn-cluster' '-Dspark.executor.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native' '-Dspark.yarn.am.extraLibraryPath=/opt/cloudera/parcels/CDH-5.4.7-1.cdh5.4.7.p0.3/lib/hadoop/lib/native' -Dspark.yarn.app.container.log.dir=/var/log/hadoop-yarn/container/application_1447669815913_0002/container_1447669815913_0002_02_000001 org.apache.spark.deploy.yarn.ApplicationMaster --class 'com.path.PathFinder' --jar file:/home/cloudera/Documents/Longest_Path_Data_1/Jars/ShortestPath_Loop-1.0.jar --arg '/home/cloudera/workspace/Spark-Integration/LongestWorstPath/configFile' --executor-memory 14336m --executor-cores 32 --num-executors 2 1> /var/log/hadoop-yarn/container/application_1447669815913_0002/container_1447669815913_0002_02_000001/stdout 2> /var/log/hadoop-yarn/container/application_1447669815913_0002/container_1447669815913_0002_02_000001/stderr 
Container killed on request. Exit code is 143 
Container exited with a non-zero exit code 143 
Failing this attempt. Failing the application. 

Dinge, die ich versucht:

1. yarn.schedular.maximum-Allocation-mb - 32GB
2. mapreduce.map.memory.mb = 2048 (Bisher war es 1024)
3. Versuchte --driver-Speicher variiert bis zu 24g

Könnten Sie bitte mehr Farbe darauf legen, wie ich den Resource Manager so konfigurieren kann, dass auch Large Size Graphs (> 300K Scheitelpunkte) verarbeitet werden können? Vielen Dank.

Answer 1

Spark-Jobs fragen Ressourcen anders als MapReduce-Jobs vom Ressourcenmanager ab. Versuchen Sie, die Anzahl der Executoren und mem/vcore, die jedem Executor zugewiesen sind, einzustellen. Folgen Sie http://spark.apache.org/docs/latest/submitting-applications.html

Answer 2

Je mehr Daten verarbeitet werden, desto mehr Speicher wird von jeder Spark-Task benötigt. Und wenn Ihr Executor zu viele Aufgaben ausführt, kann der Arbeitsspeicher knapp werden. Wenn ich Probleme bei der Verarbeitung großer Datenmengen hatte, war dies normalerweise darauf zurückzuführen, dass die Anzahl der Kerne pro Executor nicht ordnungsgemäß ausgeglichen wurde. Versuchen Sie entweder die Anzahl der Kerne zu reduzieren oder den Executor-Speicher zu erhöhen.

Eine einfache Möglichkeit zu erkennen, dass Sie Probleme mit dem Arbeitsspeicher haben, besteht darin, die Registerkarte Executor auf der Spark UI zu überprüfen. Wenn Sie viele rote Balken sehen, die auf eine hohe Zeit für die Speicherbereinigung hindeuten, haben Sie wahrscheinlich in Ihren Executoren nicht mehr genug Speicher.