Le rapport d'application pour application_ (état: ACCEPTED) ne se termine jamais pour Spark Submit (avec Spark 1.2.0 sur YARN)
J'utilise kinesis plus spark application https://spark.Apache.org/docs/1.2.0/streaming-kinesis-integration.html
Je cours comme ci-dessous
commande sur l'instance ec2:
./spark/bin/spark-submit --class org.Apache.spark.examples.streaming.myclassname --master yarn-cluster --num-executors 2 --driver-memory 1g --executor-memory 1g --executor-cores 1 /home/hadoop/test.jar
J'ai installé spark sur EMR.
EMR details
Master instance group - 1 Running MASTER m1.medium
1
Core instance group - 2 Running CORE m1.medium
Je reçois au-dessous d'INFO et cela ne finit jamais.
15/06/14 11:33:23 INFO yarn.Client: Requesting a new application from cluster with 2 NodeManagers
15/06/14 11:33:23 INFO yarn.Client: Verifying our application has not requested more than the maximum memory capability of the cluster (2048 MB per container)
15/06/14 11:33:23 INFO yarn.Client: Will allocate AM container, with 1408 MB memory including 384 MB overhead
15/06/14 11:33:23 INFO yarn.Client: Setting up container launch context for our AM
15/06/14 11:33:23 INFO yarn.Client: Preparing resources for our AM container
15/06/14 11:33:24 INFO yarn.Client: Uploading resource file:/home/hadoop/.versions/spark-1.3.1.e/lib/spark-Assembly-1.3.1-hadoop2.4.0.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/spark-Assembly-1.3.1-hadoop2.4.0.jar
15/06/14 11:33:29 INFO yarn.Client: Uploading resource file:/home/hadoop/test.jar -> hdfs://172.31.13.68:9000/user/hadoop/.sparkStaging/application_1434263747091_0023/test.jar
15/06/14 11:33:31 INFO yarn.Client: Setting up the launch environment for our AM container
15/06/14 11:33:31 INFO spark.SecurityManager: Changing view acls to: hadoop
15/06/14 11:33:31 INFO spark.SecurityManager: Changing modify acls to: hadoop
15/06/14 11:33:31 INFO spark.SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(hadoop); users with modify permissions: Set(hadoop)
15/06/14 11:33:31 INFO yarn.Client: Submitting application 23 to ResourceManager
15/06/14 11:33:31 INFO impl.YarnClientImpl: Submitted application application_1434263747091_0023
15/06/14 11:33:32 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:32 INFO yarn.Client:
client token: N/A
diagnostics: N/A
ApplicationMaster Host: N/A
ApplicationMaster RPC port: -1
queue: default
start time: 1434281611893
final status: UNDEFINED
tracking URL: http://172.31.13.68:9046/proxy/application_1434263747091_0023/
user: hadoop
15/06/14 11:33:33 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:34 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:35 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:36 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:37 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:38 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:39 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:40 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
15/06/14 11:33:41 INFO yarn.Client: Application report for application_1434263747091_0023 (state: ACCEPTED)
Quelqu'un pourrait-il me dire, s'il vous plaît, pourquoi cela ne fonctionne pas?
J'ai eu ce problème exact lorsque plusieurs utilisateurs essayaient de fonctionner sur notre cluster à la fois. Le correctif consistait à modifier les paramètres du planificateur.
Dans le fichier /etc/hadoop/conf/capacity-scheduler.xml nous avons changé la propriété yarn.scheduler.capacity.maximum-am-resource-percent de 0.1 à 0.5.
La modification de ce paramètre augmente la fraction des ressources mises à disposition pour être allouées aux maîtres des applications, augmentant le nombre de maîtres pouvant être exécutés simultanément et, partant, augmentant le nombre d'applications simultanées possibles.
J'ai eu cette erreur dans cette situation:
- MASTER = fil (ou fil-client)
- spark-submit s'exécute sur un ordinateur en dehors du cluster et il n'y a aucune route du cluster à destination car il est masqué par un routeur
Journaux pour conteneur_1453825604297_0001_02_000001 (à partir de l'interface utilisateur Web de ResourceManager):
16/01/26 08:30:38 INFO fil.ApplicationMaster: en attente de Spark doit être accessible. 16/01/26 08:31 : 41 ERREUR yarn.ApplicationMaster: Échec de la connexion au pilote à 192.168.1.180:33074, nouvelle tentative ... 16/01/26 08:32:44 ERREUR yarn.ApplicationMaster: Échec de la connexion au pilote à 192.168 .1.180: 33074, nouvelle tentative ... 16/01/26 08:32:45 ERREUR yarn.ApplicationMaster: Exception non capturée: Org.Apache.spark.SparkException: Échec de la connexion au pilote. ! à l'adresse org.Apache.spark.deploy.yarn.ApplicationMaster.waitForSparkDriver (ApplicationMaster.scala: 484)
Pour résoudre ce problème, utilisez le mode grappe de fils: MASTER = grappe-fil.
Sur un autre ordinateur configuré de la même manière, mais dont l'adresse IP est accessible à partir du cluster, le travail fil-client et le travail fil-cluster.
D'autres peuvent rencontrer cette erreur pour différentes raisons, et le fait est que la vérification des journaux d'erreurs (visibles depuis le terminal, mais l'interface utilisateur Web de ResourceManager dans ce cas) est presque toujours utile.
Cela suggère que YARN ne peut pas affecter de ressources pour la nouvelle application que vous soumettez. Essayez de réduire les ressources pour le conteneur que vous demandez (voir here ), ou essayez ceci sur un cluster moins occupé.
Une autre chose à essayer est de vérifier si YARN fonctionne correctement en tant que service:
Sudo service hadoop-yarn-nodemanager status
Sudo service hadoop-yarn-resourcemanager status
Nous pouvons essayer de résoudre ce problème de trois manières.
- Vérifiez le processus spark sur votre ordinateur et tuez-le.
Faire
ps aux | grep spark
Prenez tous les identifiants de processus avec spark processus et tuez-les, comme
Sudo kill -9 4567 7865
- Vérifiez le nombre d'applications spark exécutées sur votre cluster.
Pour vérifier cela, faites
yarn application -list
vous obtiendrez une sortie similaire à celle-ci:
Total number of applications (application-types: [] and states: [SUBMITTED, ACCEPTED, RUNNING]):1
Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL
application_1496703976885_00567 ta da SPARK cloudera default RUNNING UNDEFINED 20% http://10.0.52.156:9090
Vérifiez si les identificateurs d'application, s'ils sont plus de 1 ou plus de 2, les tuer. Votre cluster ne peut pas exécuter plus de 2 spark applications en même temps. Je ne suis pas sûr à 100% à ce sujet, mais sur un cluster si vous en exécutez plus de deux spark = applications, il va commencer à se plaindre. Alors, tuez-les Faites ceci pour les tuer:
yarn application -kill application_1496703976885_00567
- Vérifiez vos paramètres de configuration spark. Par exemple, si vous avez défini davantage de mémoire d'exécuteur ou de pilote ou le nombre d'exécuteurs sur votre application spark qui pourrait également causer Donc, réduisez l’un d’eux et lancez votre application spark, cela pourrait le résoudre.
J'ai eu un petit cluster où les ressources étaient limitées (~ 3 Go par nœud). Résolu ce problème en modifiant l'allocation de mémoire minimale en un nombre suffisamment faible.
De:
yarn.scheduler.minimum-allocation-mb: 1g
yarn.scheduler.increment-allocation-mb: 512m
À:
yarn.scheduler.minimum-allocation-mb: 256m
yarn.scheduler.increment-allocation-mb: 256m
Dans mon cas, je vois des vieux spark (qui sont arrêtés par Ctrl + Z) qui sont toujours en cours d'exécution et leurs AppMasters (pilotes) occupant probablement encore de la mémoire. Ainsi, les nouveaux AppMaster de new = La commande spark peut attendre indéfiniment pour être enregistrée par YarnScheduler, car spark.driver.memory ne peut pas être alloué dans les nœuds principaux respectifs. Cela peut également se produire lorsque l'allocation de ressource max est vraie et si le pilote est défini. utiliser le nombre maximal de ressources disponibles pour un nœud principal.
J'ai donc identifié tous ces processus obsolètes spark client et les ai tués (ce qui peut avoir tué leurs pilotes et libéré de la mémoire).
ps -aux | grep spark
hadoop 3435 1.4 3.0 3984908 473520 pts/1 Tl Feb17 0:12 .. org.Apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.Apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 10
hadoop 32630 0.9 3.0 3984908 468928 pts/1 Tl Feb17 0:14 .. org.Apache.spark.deploy.SparkSubmit --conf spark.driver.memory=1G --class org.Apache.spark.examples.SparkPi /usr/lib/spark/lib/spark-examples.jar 1000
kill -9 3435 32630
Après cela, je ne vois pas ces messages.
Je suis sur une configuration légèrement différente en utilisant CDH 5.4. Je pense que la cause de ce problème sur mon installation est quelque chose qui reste bloqué à cause d'une erreur (le fichier existe déjà, etc.), car cela se produit après qu'une autre partie de mes erreurs de code soit sortie et que l'on essaie de le réparer à nouveau.
Je peux surmonter ce problème en redémarrant tous les services du cluster dans Cloudera Manager. Je suis donc d’accord avec les réponses précédentes, selon lesquelles cela est probablement dû aux ressources allouées à une tâche qui a fait l’objet d’une erreur et que vous devez récupérer ces ressources pour pouvoir les exécuter. encore, ou les allouer différemment pour commencer.
par exemple. Mon cluster a 4 exécuteurs disponibles. Dans SparkConf pour un processus, j'ai défini spark.executor.instances sur 4. Pendant que ce processus est toujours en cours d'exécution, potentiellement bloqué, je lance un autre travail (de la même manière, ou avec spark-submit), avec spark. executor.instances a la valeur 1 ("--num-executors 1" si vous utilisez spark-submit). Je n'en ai que 4, et 4 sont affectés au processus précédent, donc celui qui demande 1 exécuteur doit attendre.
Dans un cas, j'avais ce problème parce que je demandais trop de ressources. C'était sur un petit cluster autonome. La commande originale était
spark-submit --driver-memory 4G --executor-memory 7G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar
J'ai réussi à aller au-delà de "Accepted" et à "Running" en changeant pour
spark-submit --driver-memory 1G --executor-memory 3G -class "my.class" --master yarn --deploy-mode cluster --conf spark.yarn.executor.memoryOverhead my.jar
Dans d'autres cas, j'ai eu ce problème en raison de la façon dont le code a été écrit. Nous avons instancié le contexte spark à l'intérieur de la classe où il a été utilisé et il n'a pas été fermé. Nous avons résolu le problème en instanciant d'abord le contexte, en le transmettant à la classe où les données sont parallélisées, etc. puis fermer le contexte (sc.close ()) dans la classe de l'appelant.
J'ai eu le même problème sur un cluster hadoop local avec spark 1.4 et fil, en essayant d'exécuter spark-Shell. Il avait plus de ressources suffisantes.
Ce qui a aidé a été d'exécuter la même chose à partir d'un travail interactif de lsf sur le cluster. Alors peut-être y avait-il des limitations de réseau pour exécuter le fil à partir du noeud principal ...
Je frappe le même problème cluster MS Azure dans leur HDinsight spark cluster.
a finalement découvert que le problème était que le cluster ne pouvait pas répondre au conducteur. Je suppose que vous avez utilisé le mode client lors de la soumission du travail, car vous pouvez fournir ce journal de débogage.
la raison en est que spark les exécuteurs doivent parler au programme du pilote et la connexion TCP doit être bidirectionnelle. Ainsi, votre programme de pilote est exécuté en une VM (instance ec2) qui n’est pas accessible via nom d’hôte ou IP (vous devez spécifier dans spark conf, nom d’hôte par défaut)), votre statut sera accepté pour toujours.
Lors de l'exécution avec yarn-cluster, toute la journalisation et la sortie standard de l'application seront situées dans le maître d'application de fil attribué et ne paraîtront pas comme des étincelles. Le fait de diffuser également l'application ne se ferme généralement pas. Vérifiez l'interface Web du gestionnaire de ressources Hadoop et consultez le Spark) et les journaux qui seront disponibles à partir de l'interface utilisateur Hadoop.