web-dev-qa-db-fra.com

Spark - Le conteneur dépasse les limites de la mémoire physique

J'ai un cluster de deux nœuds de travail. Worker_Node_1 - 64 Go de RAM Worker_Node_2 - 32 Go de RAM

Résumé de l'arrière-plan: J'essaie d'exécuter un envoi par étincelle sur un groupe de fils pour exécuter Pregel sur un graphique afin de calculer les distances de chemin les plus courtes entre un sommet source et tous les autres sommets et d'imprimer les valeurs. sur console. Expérience:

  1. Pour le graphique de petite taille avec 15 sommets, le statut final de l'application est terminé: SUCCEEDED
  2. Mon code fonctionne parfaitement et affiche la distance la plus courte pour un graphique de 241 sommets pour un sommet unique en tant que sommet source, mais il y a un problème.

Problème: Lorsque je creuse dans le fichier journal, la tâche est terminée avec succès en 4 minutes et 26 secondes, mais toujours sur le terminal, il continue d'afficher l'état de l'application sous la forme En cours d'exécution et après environ 12 minutes supplémentaires, l'exécution de la tâche se termine en disant -

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.

Ce que j'ai essayé:  

  1. yarn.schedular.maximum-allocation-mb - 32Go 
  2. mapreduce.map.memory.mb = 2048 (auparavant, c'était 1024)
  3. Essayé de varier --driver-memory jusqu'à 24g

Pourriez-vous s'il vous plaît mettre plus de couleur sur la façon dont je peux configurer le gestionnaire de ressources afin que les graphiques de grande taille (> 300K sommets) puissent également être traités? Merci.

hadoopapache-sparkspark-graphx
10
aditya

Plus vous traitez de données, plus chaque tâche Spark nécessite de la mémoire. Et si votre exécuteur exécute trop de tâches, il risque de manquer de mémoire. Lorsque je rencontrais des problèmes pour traiter de grandes quantités de données, c’était généralement dû au fait que le nombre de cœurs par exécuteur n’était pas correctement équilibré. Essayez de réduire le nombre de cœurs ou d’augmenter la mémoire de l’exécuteur.

Un moyen simple de savoir que vous rencontrez des problèmes de mémoire consiste à vérifier l'onglet Executor dans l'interface utilisateur de Spark. Si vous voyez beaucoup de barres rouges indiquant un temps de récupération élevé, vous manquerez probablement de mémoire dans vos exécuteurs. 

2
Ted

Je corrige l'erreur dans mon cas d'augmenter la valeur de spark.yarn.executor.memoryOverhead Qui signifie mémoire off-tas Lorsque vous augmentez la quantité de mémoire pilote et de mémoire exécuteur, ne le faites pas. oublier cet élément de configuration

1
Gavin Gu

Les tâches Spark demandent des ressources au gestionnaire de ressources différemment des tâches MapReduce. Essayez d’ajuster le nombre d’exécuteurs et de mem/vcore alloués à chaque exécuteur. Suivez http://spark.Apache.org/docs/latest/submitting-applications.html

0
Kai

Il suffit d'augmenter la valeur par défaut de spark.driver.memory de 512m à 2g pour résoudre cette erreur dans mon cas. 

Vous pouvez augmenter la mémoire si elle continue à frapper la même erreur. Ensuite, vous pouvez continuer à la réduire jusqu'à ce que la même erreur se produise, afin de connaître la mémoire optimale du pilote à utiliser pour votre travail. 

0
Wong Tat Yau