web-dev-qa-db-fra.com

Airflow 1.9.0 met en file d'attente mais ne lance pas de tâches

Airflow n'exécute pas de manière aléatoire les tâches en file d'attente. Certaines tâches ne reçoivent même pas le statut en file d'attente. Je continue à voir ci-dessous dans les journaux du planificateur

 [2018-02-28 02:24:58,780] {jobs.py:1077} INFO - No tasks to consider for execution.

Je vois des tâches dans la base de données qui n'ont pas de statut ou qui sont en file d'attente mais ne sont jamais démarrées.

La configuration du flux d'air est en cours d'exécution https://github.com/puckel/docker-airflow sur ECS avec Redis. Il existe 4 threads de planificateur et 4 tâches de travailleur Celery. Les tâches qui ne sont pas en cours s'affichent en file d'attente (icône grise) lorsque la souris survole l'opérateur icône de la tâche est null et que les détails de la tâche indiquent:

    All dependencies are met but the task instance is not running. In most cases this just means that the task will probably be scheduled soon unless:- The scheduler is down or under heavy load

Les métriques sur le planificateur ne montrent pas de charge lourde. Le dag est très simple avec 2 tâches indépendantes qui ne dépendent que de la dernière exécution. Il y a aussi des tâches dans le même dag qui sont bloquées sans statut (icône blanche).

Ce qu'il y a d'intéressant à remarquer, c'est quand je redémarre lorsque les tâches du planificateur passent à l'état d'exécution.

airflowairflow-scheduler
29
l0n3r4ng3r

Le flux d'air peut être un peu difficile à configurer.

  • As-tu le airflow scheduler fonctionnement?
  • As-tu le airflow webserver fonctionnement?
  • Avez-vous vérifié que tous les DAG que vous souhaitez exécuter sont définis sur On dans l'interface utilisateur Web?
  • Tous les groupes de disponibilité de base de données que vous souhaitez exécuter ont-ils une date de début ancienne?
  • Est-ce que tous les groupes de disponibilité de base de données que vous souhaitez exécuter ont un calendrier approprié, affiché dans l'interface Web?
  • Si rien d'autre ne fonctionne, vous pouvez utiliser l'interface Web pour cliquer sur le dag, puis sur Graph View . Maintenant, sélectionnez la première tâche et cliquez sur Instance de tâche . Dans le paragraphe Détails de l'instance de tâche , vous verrez pourquoi un DAG attend ou ne s'exécute pas.

J'ai eu par exemple un DAG mal réglé sur depends_on_past: True qui interdit à l'instance actuelle de démarrer correctement.

C'est aussi une excellente ressource directement dans la documentation, qui contient quelques astuces supplémentaires: Pourquoi ma tâche n'est-elle pas planifiée? .

39
tobi6

Je suis également en train de lancer un dépôt du référentiel puckel/docker-airflow, principalement sur Airflow 1.8 pendant environ un an avec plus de 10 millions d'instances de tâches. Je pense que le problème persiste en 1.9, mais je ne suis pas positif.

Pour une raison quelconque, il semble exister un problème de longue date avec le planificateur Airflow, dans lequel les performances se dégradent avec le temps. J'ai examiné le code du planificateur, mais je ne comprends toujours pas ce qui se passe exactement différemment lors d'un nouveau départ, ce qui me permet de revenir à la planification normalement. Une différence majeure est que les états des tâches planifiées et en file d'attente sont reconstruits.

Principes de base du planificateur dans le wiki Airflow fournit une référence concise sur le fonctionnement du planificateur et ses différents états.

La plupart des gens résolvent le problème de diminution du débit du planificateur en le redémarrant régulièrement. J'ai personnellement rencontré le succès à une heure d'intervalle, mais je l'ai utilisé aussi souvent que toutes les 5 à 10 minutes. Les paramètres de volume, de durée et de parallélisme des tâches méritent d’être pris en compte lors de l’expérimentation d’un intervalle de redémarrage.

Pour plus d'informations, voir:

Auparavant, ce problème était résolu en redémarrant chaque X en utilisant le SCHEDULER_RUNS paramètre de configuration , bien que ce paramètre soit récemment supprimé à partir des scripts systemd par défaut.

Vous pouvez également envisager de poster sur la liste de diffusion de Airflow dev . Je sais que cela a déjà été abordé à plusieurs reprises et l’un des principaux contributeurs pourrait peut-être fournir un contexte supplémentaire.

Questions connexes

12
Taylor Edmiston

Je suis confronté au problème aujourd'hui et ai constaté que le point 4 de tobi6 la réponse ci-dessous a fonctionné et résolu le problème

*'Do all the DAGs you want to run have a start date which is in the past?'*

J'utilise airflow version v1.10.3

4
Shahbaz Ali

Mon problème était un peu plus loin, en plus de mes tâches en file d'attente, je ne pouvais voir aucun de mes ouvriers du céleri sur l'interface utilisateur de Flower. La solution était que, depuis que je travaillais sur le céleri-rave en tant que root, je devais apporter des modifications à mon fichier ~/.bashrc.

Les étapes suivantes ont fonctionné:

  1. Ajoutez l'exportation C_FORCE_ROOT = true à votre fichier ~/.bashrc
  2. source ~/.bashrc
  3. Exécutez worker: Nohup airflow worker $ * >> ~ ~/airflow/logs/worker.logs &

Vérifiez votre interface utilisateur Fleur à l'adresse http: // {Host}: 5555.

1
Prithu Srinivas

Je pense que c'est un problème avec le céleri version 4.2.1 et Redis 3.0.1 comme décrit ici:

https://github.com/celery/celery/issues/3808

nous avons résolu le problème en rétrogradant notre version 2.10.6 de Redis:

redis==2.10.6

0
randal25

Une dernière chose à vérifier est de savoir si "le paramètre de simultanéité de votre DAG est atteint?" .

J'avais connu la même situation lorsqu'une tâche était représentée par NO STATUS .

Il s’est avéré que mes tâches File_Sensor étaient exécutées avec un délai d’expiration défini sur une semaine, alors que le délai d’expiration du DAG était de 5 heures seulement. Cela a conduit au cas où les fichiers étaient manquants, de nombreux capteurs chargés fonctionnaient en même temps. Il en résulte la concurrence surchargée!

Les tâches dépendantes ne pouvaient pas être démarrées avant que la tâche de détection ne réussisse. Une fois le délai d'expiration écoulé, elles obtenaient NO STATUS .

Ma solution:

  • Définissez soigneusement les tâches et le délai d'expiration du DAG
  • Augmentez dag_concurrency dans le fichier airflow.cfg du dossier AIRFLOW_HOME.

Veuillez vous référer à la documentation. https://airflow.Apache.org/faq.html#why-isn-t-my-task-getting-scheduled

0
Nhat Cuong Ha

J'ai également eu un problème similaire, mais il est principalement lié à SubDagOperator avec plus de 3000 instances de tâches au total (30 tâches * 44 tâches de subdag).

Ce que j'ai découvert, c'est que airflow scheduler principalement responsable de mettre vos tâches planifiées dans "Sleued Slots" (pool), tandis que airflow celery workers est celui qui récupère votre tâche en file d'attente et la met dans le "Emplacements utilisés" (pool) et l'exécute.

Selon votre description, votre scheduler devrait fonctionner correctement. Je vous suggère de vérifier votre journal "travailleurs de céleri" pour voir s'il y a une erreur, ou de le redémarrer pour voir si cela aide ou non. J'ai eu quelques problèmes qui font que les travailleurs de céleri font la grève pendant quelques minutes puis recommencent à travailler (en particulier sur SubDagOperator)

0
Kevin Li