Airflow 1.9.0正在排队,但没有启动任务

Question

气流随机不运行排队任务有些任务甚至没有排队状态.我在调度程序日志中一直看到以下内容

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

我确实看到数据库中的任务没有状态或排队状态,但它们永远不会开始.

气流设置在ECS上使用Redis 运行https://github.com/puckel/docker-airflow.有4个调度程序线程和4个Celery工作程序任务.当悬停在任务图标上时,未运行的任务显示在排队状态(灰色图标)操作符为空,任务详细信息显示:

    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

调度程序上的度量标准不会显示负载.dag非常简单,2个独立任务仅取决于最后一次运行.同一个dag中的任务也没有状态(白色图标).

有趣的是要注意的是,当我重新启动调度程序时,任务更改为运行状态.

Answer 1

设置气流可能有点棘手.

• 你有airflow scheduler跑步吗？
• 你有airflow webserver跑步吗？
• 您是否已检查过您要运行的所有DAG是否已在Web ui 中设置为On？
• 您想要运行的所有DAG都有一个过去的开始日期吗？
• 您想要运行的所有DAG是否都有一个适当的时间表,该时间表显示在web ui中？
• 如果没有其他工作,你可以使用web ui点击dag,然后点击Graph View.现在选择第一个任务,然后单击Task Instance.在段落任务实例详细信息中,您将看到DAG正在等待或未运行的原因.

我有一个DAG错误地设置为depends_on_past: True禁止当前实例正确启动.

也是直接在文档中的一个很好的资源,它有一些提示:为什么我的任务没有安排好？.

Answer 2

我正在运行puckel/docker-airflow repo的一个分支,主要在Airflow 1.8上运行大约一年,有10M +任务实例.我认为这个问题在1.9中仍然存在,但我并不积极.

无论出于何种原因,Airflow调度程序似乎存在一个长期存在的问题,即性能会随着时间的推移而降低.我已经查看了调度程序代码,但是我仍然不清楚在一个新的开始时究竟会发生什么样的事情才能重新开始调度.一个主要区别是重建了计划任务状态和排队任务状态.

Airflow wiki中的Scheduler Basics提供了有关调度程序如何工作及其各种状态的简明参考.

大多数人通过定期重新启动调度程序来解决调度程序减少吞吐量问题.我个人间隔1小时就找到了成功,但每隔5-10分钟也经常看到.在尝试重启间隔时,您的任务量,任务持续时间和并行度设置值得考虑.

有关详情,请参阅:

• 气流:提示,技巧和陷阱("应该经常重启调度程序"部分)
• 错误1286825 - 气流调度程序无声地停止工作
• WePay上的气流("在部署DAG更改时重新启动所有内容"部分.)

过去通过使用SCHEDULER_RUNS配置设置重新启动每个X运行来解决这个问题,尽管最近从默认的systemd脚本中删除了该设置.

您也可以考虑发布到Airflow开发邮件列表.我知道这已经在那里讨论了几次,其中一个核心贡献者可能能够提供额外的上下文.

相关问题

• 气流任务陷入"排队"状态,永远不会运行(特别是在这里看到Bolke的答案)
• 作业不是通过使用RabbitMQ运行芹菜的Airflow执行的

Answer 3

我也有类似的问题，但主要与 SubDagOperator 相关，总共有 3000 多个任务实例（30 个任务 * 44 个 subdag 任务）。

我发现它airflow scheduler主要负责将您的计划任务放入“Queued Slots”（池）中，而airflow celery workers将您的排队任务放入“Used Slots”（池）并运行它的人。

根据您的描述，您scheduler应该可以正常工作。我建议您检查您的“芹菜工人”日志以查看是否有任何错误，或者重新启动它以查看是否有帮助。我遇到了一些问题，芹菜工人通常会罢工几分钟然后重新开始工作（尤其是在 SubDagOperator 上）

Answer 4

确保您没有datetime.now()作为 start_date

直觉上认为，如果您告诉 DAG“现在”开始，它就会“现在”执行。但是，这并没有考虑到 Airflow 本身实际上如何读取datetime.now().

对于要执行的 DAG，start_date 必须是过去的时间，否则 Airflow 会认为它尚未准备好执行。当 Airflow 评估您的 DAG 文件时，它会解释datetime.now()为当前时间戳（即不是过去的时间）并决定它尚未准备好运行。由于每次 Airflow 心跳（评估您的 DAG）每 5-10 秒都会发生这种情况，因此它永远不会运行。

要正确触发 DAG 运行，请确保插入过去的固定时间（例如 datetime(2019,1,1)）并设置 catchup=False（除非您要运行回填）。

按照设计，Airflow DAG 将在其 schedule_interval 完成时执行

这意味着在开始日期之后一个 schedule_interval。例如，每小时的 DAG 将在时钟敲响 3 点时执行其下午 2 点的运行。这里的推理是 Airflow 无法确保与下午 2 点间隔对应的所有数据都存在，直到该每小时间隔结束。

这是 Airflow 的一个特殊方面，但要记住这一点很重要——尤其是当您使用默认变量和宏时。

Airflow 中的时间默认为 UTC

鉴于您的其余数据库和 API 很可能也遵循这种格式，这应该不足为奇，但值得澄清。

全文和来源在这里

Answer 5

其中一个非常愚蠢的原因可能是 DAG 第一次处于“暂停”状态，这是默认状态。我花了大约2个小时的时间来对抗它。如果您使用 Airflow Web 界面，则会在列表中的 DAG 旁边显示为切换开关