Rapport d'Application pour application_ (état: ACCEPTÉ) n'en finit pas d'Étincelles Soumettre (avec Spark 1.2.0 sur le FIL)

Je suis en cours d'exécution kinesis plus spark application
https://spark.apache.org/docs/1.2.0/streaming-kinesis-integration.html

Je suis en cours d'exécution comme ci-dessous

de commande sur une 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é étincelle sur les EMR.

EMR details
Master instance group - 1   Running MASTER  m1.medium   
1

Core instance group - 2 Running CORE    m1.medium

Je suis en dessous de l'INFO et il ne se termine 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 s'il vous plaît laissez-moi savoir pourquoi ça ne fonctionne pas ?

  • Alexei51: "Peut-être supprimer setMaster("local[*]")"
InformationsquelleAutor Sam | 2015-06-14
  1. 21

    J'ai eu exactement ce problème lorsque plusieurs utilisateurs ont essayé de s'exécuter sur notre cluster à la fois. La solution était de changer le réglage de l'ordonnanceur.

    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 qui est disponible pour être affecté à l'application des maîtres, l'augmentation du nombre de maîtres possible d'exécuter à la fois et donc à augmenter le nombre de possibles applications simultanées.

    • Tiens juste à ajouter que c'est un paramètre très important à régler, si vous êtes cluster en cours d'exécution sur un seul ordinateur où vos ressources sont de petits
    • je travaille dans la TEINTE, j'ai aussi le même problème. où je peux trouver capacity-scheduler.xml fichier
    • a travaillé pour moi. il est possible d'exécuter plusieurs Étincelle applications maintenant
    InformationsquelleAutor Jem Tucker
  2. 14

    J'ai eu cette erreur dans cette situation:

    1. MASTER=fils (ou fil-client)
    2. étincelle soumettre s'exécute sur un ordinateur à l'extérieur de la grappe et il n'y a pas de route à partir de la grappe, car il est caché par un routeur

    Journaux pour container_1453825604297_0001_02_000001 (à partir de la classe ResourceManager INTERFACE web): 

    16/01/26 08:30:38 INFO fil.ApplicationMaster: en Attente d'Étincelle pilote, afin d'être joignable. 
16/01/26 08:31:41 ERREUR de fil.ApplicationMaster: impossible de se connecter à un chauffeur à 192.168.1.180:33074, réessayer ... 
16/01/26 08:32:44 ERREUR de fil.ApplicationMaster: impossible de se connecter à un chauffeur à 192.168.1.180:33074, réessayer ... 
16/01/26 08:32:45 ERREUR de fil.ApplicationMaster: Uncaught exception: 
org.apache.spark.SparkException: impossible de se connecter au pilote! 
au org.apache.spark.déployer.de fil.ApplicationMaster.waitForSparkDriver(ApplicationMaster.scala:484)

    Je le contourner en utilisant des fils de mode de cluster: MASTER=fil-cluster.

    Sur un autre ordinateur qui est configuré de la même façon, mais est l'IP est accessible à partir de la grappe, les deux fils de client et de fils-cluster de travail.

    D'autres peuvent rencontrer cette erreur pour différentes raisons, et de mon point est que la vérification des journaux d'erreur (pas vu depuis le terminal, mais ResourceManager de l'INTERFACE web dans ce cas) presque toujours de l'aide.

    • même problème que le votre cas. devrait être une table de routage question.
    • Merci pour cette explication!
    InformationsquelleAutor pzy
  3. 6

    Ceci suggère que les FILS ne peut pas affecter des ressources pour la nouvelle Application que vous soumettez. Essayez de réduire les ressources pour le conteneur que vous demandez (voir ici), ou à essayer au moins occupé de cluster.

    Une autre chose à essayer est de vérifier si le FIL fonctionne correctement en tant que service:

    sudo service hadoop-yarn-nodemanager status
sudo service hadoop-yarn-resourcemanager status
    • Je devais commencer mon fils nodemngr. Merci!
    InformationsquelleAutor marios
  4. 3

    J'ai eu un petit cluster où les ressources étaient limitées (~3 GO par nœud). Résolu ce problème en changeant le minimum de l'allocation de mémoire à un niveau suffisamment faible nombre.

    À partir 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
    • je travaille dans la TEINTE, j'ai aussi le même problème. où je dois changer de code ci-dessus?
    InformationsquelleAutor Def_Os
  5. 3

    Il y a trois façons d'essayer de résoudre ce problème.

    1. Vérifier l'étincelle processus sur votre ordinateur et de le tuer.

    Ne 

    ps aux | grep spark

    Prendre toutes les id de processus avec spark processus et de les tuer, comme 

    sudo kill -9 4567 7865
    1. Vérifier le nombre de bougies d'applications en cours d'exécution sur votre cluster.

    Pour le vérifier, ne 

    yarn application -list

    vous permettra d'obtenir un résultat semblable à ceci:

    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érifier l'id de l'application, si ils ne sont plus que 1, ou de plus de 2, de les tuer. Votre cluster ne peut pas exécuter plus de 2 étincelle applications en même temps. Je ne suis pas 100% sûr à ce sujet, mais sur le cluster si vous exécutez plus de deux étincelle applications, il va commencer à se plaindre. Ainsi, les tuer
    Ce faire de les tuer:

    yarn application -kill application_1496703976885_00567
    1. Vérifier votre étincelle config paramètres.
      Par exemple, si vous avez défini plus exécuteur de la mémoire ou de la mémoire pilote ou de numéro de exécuteurs sur votre spark application qui peut également causer un problème. Donc, de réduire et d'exécuter votre application spark, qui pourrait le résoudre.
    InformationsquelleAutor JumpMan
  6. 1

    Je suis un peu différente configuration à l'aide de la CDH 5.4. Je pense que la cause de ce problème sur mon installation est quelque chose de coincé à cause d'une erreur (le fichier existe déjà, etc.), parce que ce qui se passe après une autre partie de mon code d'erreurs et d'essayer de les corriger et de le déclencher à nouveau.

    Je peux passer ce par le redémarrage de tous les services du cluster dans cloudera manager, je suis d'accord avec les réponses précédentes en ce qu'elle est probablement en raison des ressources qui sont allouées à quelque chose que l'erreur-ed et vous avez besoin de récupérer ces ressources pour être en mesure d'exécuter de nouveau, ou de les affecter différemment pour commencer.

    par exemple, mon cluster a 4 exécuteurs sont disponibles. Dans SparkConf pour un processus, j'ai mis de l'étincelle.exécuteur testamentaire.les instances à 4. Tout ce processus est encore en cours d'exécution, potentiellement raccroché pour une raison quelconque, j'ai le coup d'envoi d'un autre emploi (soit même, ou par étincelle soumettre), avec spark.exécuteur testamentaire.les instances de la valeur 1 ("--num exécuteurs testamentaires 1 " si, à l'aide de bougies de soumettre). Je n'ai que 4, et 4 sont consacrés au processus antérieur, de sorte que ce qui est demandé pour 1 exécuteur testamentaire a attendre en ligne.

    InformationsquelleAutor lukewitmer
  7. 1

    Dans mon cas, je vois que certains vieux étincelle processus (qui sont arrêtés par Ctrl+Z) sont toujours en cours d'exécution et leur AppMasters (pilotes) probablement encore d'occupation de la mémoire. Ainsi, la nouvelle AppMaster de nouvelle étincelle de commande peut être attendre indéfiniment pour être enregistré par YarnScheduler, comme une étincelle.le pilote.la mémoire ne peut pas être affectés dans les différents nœuds principaux. Cela peut également se produire lorsque Max allocation des ressources est vrai et si le pilote est configuré pour utiliser Max de ressources disponibles pour un core-nœud.

    Donc, j'ai identifié tous ceux rassis étincelle processus client et tué (ce qui peut avaient 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 que je ne vois pas ces messages.

    • Si vous exécutez le Fil, vous pouvez utiliser du fil de l'application de tuer <appilication-ID>. Vous pouvez vérifier le statut de vos tâches sur le port 8088, si exécute localement, directement de votre navigateur à localhost:8088. Quand je développe quelque chose au niveau local, j'ai parfois de la Ruche ou de sessions Zeppelin travaux en cours d'exécution ainsi et j'ai besoin de tuer les d'abord avant de l'Étincelle travail s'exécute.
    InformationsquelleAutor jc mannem
  8. 0

    Lors de l'exécution avec un fil de cluster de tous les journalisation de l'application et de la sortie standard (stdout) sera situé dans le fil de l'application de maître et n'apparaîtra pas à l'étincelle de la soumettre. Aussi en streaming la demande n'est généralement pas le quitter. Vérifiez les Hadoop gestionnaire de ressources de l'interface web et de regarder l'Étincelle de l'interface utilisateur web et les journaux qui sera disponible à partir de l'interface utilisateur Hadoop.

    • Ce problème semble persiste même si l'application a une fin (non streaming de traitement par lots).
    InformationsquelleAutor ChristopherB
  9. 0

    J'ai eu le même problème sur un local cluster hadoop avec étincelle de 1,4 et de fils, en essayant de lancer spark-shell. Il avait plus alors assez de ressources.

    Ce qui les a aidé a été exécutant la même chose à partir d'un lsf interactive travail sur le cluster.
    Alors peut-être il y avait certaines limites du réseau pour exécuter le fil de la tête de noeud...

    InformationsquelleAutor MichalO
  10. 0

    Dans un exemple, j'ai eu ce problème parce que j'étais en demandant trop de ressources. C'était sur une petite autonome de cluster. La commande d'origine a été

    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 à m'passé "Accepté" et en "Courant" en changeant de

    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 à cause de la façon dont le code a été écrit. Nous avons instancié l'étincelle contexte à l'intérieur de la classe où il a été utilisé, et il n'a pas fermé. Nous avons corrigé le problème en instanciant le contexte de la première, passant à la classe où les données sont mises en parallèle etc, puis de refermer le contexte (sc.close()) en l'appelant la classe.

    • --conf spark.yarn.executor.memoryOverhead. Aucune valeur?
    InformationsquelleAutor rodin
  11. 0

    J'ai frappé le même problème MS Azure cluster dans leur HDinsight étincelle de cluster.

    enfin trouvé le problème était le cluster ne pouvais pas être en mesure de parler de retour vers le pilote.
    Je suppose que vous avez utilisé en mode client lors de la soumettre le travail puisque vous pouvez offrir ce journal de débogage.

    raison en est que l'étincelle interprètes ont à parler de programme de pilote, et la connexion TCP doit être bi-directionnelle. donc, si votre programme de pilote est en cours d'exécution sur une machine virtuelle(instance ec2) qui n'est pas accessible via un nom d'hôte ou IP(vous devez spécifier dans spark conf, par défaut nom d'hôte), votre statut sera accepté pour toujours.

    InformationsquelleAutor linehrr
  12. -1

    J'ai fait face à la même question dans clouera de démarrage de la VM quand j'ai essayé d'exécuter pyspark shell . J'ai deja voir les journaux des tâches dans la classe resourcemanager , je vois 

    17/02/18 22:20:53 ERROR yarn.ApplicationMaster: Failed to connect to driver at RM IP.

    Cela signifie que l'emploi n'est pas en mesure de se connecter à RM (resource manager), car par défaut pyspark essayer de lancer au fil mode dans cloudera VM . 

    pyspark --master local

    a fonctionné pour moi . Avant même de commencer à RM s a résolu le problème.

    Grâce

    InformationsquelleAutor Suman Banerjee