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

时间：2018-02-28 02:28:51

标签： airflow airflow-scheduler

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

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

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

使用Redis在ECS上运行气流设置为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中的任务也没有状态（白色图标）。

有趣的是，当我重新启动调度程序时，任务更改为运行状态。

13 个答案:

答案 0 :(得分：29)

设置Airflow可能有点棘手。

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

例如，我有一个错误设置为depends_on_past: True的DAG，禁止当前实例正确启动。

直接在文档中提供了一个很好的资源，它还有一些提示：Why isn't my task getting scheduled?。

答案 1 :(得分：7)

我也在运行puckel / docker-airflow repo的一个分支，主要在Airflow 1.8上运行大约一年的10M +任务实例。我认为这个问题在1.9中仍然存在，但我并不乐观。

无论出于何种原因，Airflow调度程序似乎存在一个长期存在的问题，即性能会随着时间的推移而降低。我已经查看了调度程序代码，但是我仍然不清楚在重新启动时会有什么不同之处，以便重新启动调度程序。一个主要区别是重建了计划任务状态和排队任务状态。

Airflow wiki中的

Scheduler Basics提供了关于调度程序如何工作及其各种状态的简明参考。

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

有关详细信息，请参阅：

过去通过使用SCHEDULER_RUNS config setting重新启动每次X次运行来解决此问题，尽管该设置是默认systemd脚本中的recently removed。

您也可以考虑发布到Airflow dev mailing list。我知道这已经在那里讨论了几次，其中一个核心贡献者可能能够提供额外的背景。

相关问题

答案 2 :(得分：2)

确保您没有datetime.now()作为开始日期

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

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

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

根据设计，Airflow DAG将在其schedule_interval完成时执行

这意味着在开始日期之后一个schedule_interval。例如，每小时DAG将在时钟为下午3点时执行其下午2点运行。这样做的原因是，Airflow不能确保在该小时间隔结束之前，存在与2pm间隔相对应的所有数据。

这是Airflow的一个特殊方面，但要记住一个重要方面-特别是在使用默认变量和宏的情况下。

默认情况下，气流时间为UTC

鉴于您的其余数据库和API最有可能也遵循这种格式，因此这不足为奇，但是值得澄清。

全文和来源here

答案 3 :(得分：1)

我今天面对这个问题，发现下面的 tobi6 答案中的要点4解决了问题

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

我正在使用气流版本v1.10.3

答案 4 :(得分：1)

我的问题又往上走了一步，除了我的任务正在排队，我在Flower UI上看不到我的任何芹菜工人。解决方案是，由于我以根用户身份运行celery worker，因此必须在〜/ .bashrc文件中进行更改。

以下步骤使其有效：

  1. 将export C_FORCE_ROOT = true添加到您的〜/ .bashrc文件中
  2. 源〜/ .bashrc
  3. 运行工人：nohup气流工人$ * >>〜/ airflow / logs / worker.logs＆

通过以下网址检查您的Flower UI：http：// {HOST}：5555

答案 5 :(得分：1)

您可以尝试停止Web服务器和调度程序：

ps -ef | grep airflow       #show the process id
kill 1234                   #kill the webserver
kill 5678                   #kill the scheduler

从airflow文件夹中删除文件（如果存在）（它们将再次创建）：

airflow-scheduler.err
airflow-scheduler.pid
airflow-webserver.err
airflow-webserver.pid

再次启动Web服务器和调度程序。

airflow webserver -D
airflow scheduler -D

-D将使服务在后台运行。

答案 6 :(得分：0)

要检查的另一件事是“是否达到了DAG的并发参数？” 。

当某些任务显示为无状态时，我也遇到了同样的情况。

原来，我的File_Sensor任务是在超时设置为1周的情况下运行的，而DAG超时仅为5小时。这导致文件丢失的情况，许多任务传感器同时运行。导致并发超载！

依赖任务无法在传感器任务成功之前启动，当dag超时时，它们变为无状态。

我的解决方案：

  • 精心设置任务和DAG 超时
  • 增加AIRFLOW_HOME文件夹中airflow.cfg文件中的 dag_concurrency 。

请参考文档。 https://airflow.apache.org/faq.html#why-isn-t-my-task-getting-scheduled

答案 7 :(得分：0)

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

我发现，airflow scheduler主要负责将计划的任务放入“排队的插槽”（池），而airflow celery workers是负责将排队的任务放入其中的人“已用插槽”（池）并运行它。

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

答案 8 :(得分：0)

我认为这是celery 4.2.1和redis 3.0.1的问题，如下所述：

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

我们通过降级Redis版本2.10.6解决了该问题：

redis==2.10.6

答案 9 :(得分：0)

我认为值得一提的是，有一个公开的问题可能导致任务在没有明显原因的情况下无法运行：https://issues.apache.org/jira/browse/AIRFLOW-5506

使用LocalScheduler连接到PostgreSQL气流数据库时，似乎会出现此问题，并导致调度程序记录了许多“杀死PID xxxx”行。在DAG停止后，请检查调度程序日志，并且暂时不启动任何新任务。

答案 10 :(得分：0)

在我的情况下，没有启动任务，因为我为所有操作员配置了一个池，但尚未创建它，因此甚至没有安排任务。运算符如下：

<?php
  if($checkGallery):
?>
    <td><?= This post has a gallery! ?></td>
<?php else: ?>
    <td><?= No gallery attached to this post.?></td>
<?php endif;?>

要创建池，请进入管理>池>创建并设置插槽，例如128，该插槽对我而言已成功运行。您也可以使用here进行配置。

答案 11 :(得分：0)

counter intuitive UI message! 我已经花了几天的时间。所以想详细说明我的具体问题。

每个 dag 都有一个状态。默认情况下，状态可以是“暂停”或“不暂停”。

第一个困惑来自 - 启动时的默认状态是什么？附加的 UI 消息似乎表明状态为“未暂停”，单击切换按钮时，它会暂停。

实际上，默认状态是“暂停”。这种状态可以通过设置、环境变量、参数和 UI 来控制。我在下面详细介绍了它们。

由于 UI 再次出现了第二个混淆。当我们手动触发处于暂停状态的 dag 时。 UI 显示 dag 正在运行（绿色圆圈）！但 dag 实际上处于“暂停”状态。除非“取消暂停”，否则不会执行任务。

如果我们阅读任务实例详细信息。消息将是

Task is in the 'None' state which is not a valid state for execution. The task must be cleared in order to be run.

什么是“无”状态！？并明确哪个任务？！

实际问题是dag处于暂停状态。在切换 dag 状态时，任务将开始执行。

dag 的暂停状态可以通过

改变
  • 点击用户界面上的按钮。
  • 通过将以下参数添加到您的 dag 来设置您的特定 dag 运行
DAG(dag_id='your-dag', is_paused_upon_creation=True)
  • 在airflow.cfg 文件中设置配置变量。 （注意：这将启动您的所有 dag，包括示例）
dags_are_paused_at_creation = FALSE
  • 在启动调度程序/网络服务器之前配置一个环境变量。（注意：这将启动包括示例在内的所有 dag）
AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION=False

答案 12 :(得分：0)

我遇到了类似的问题，触发 DAG 无限期“运行”，因为它的第一个任务卡在“排队”状态。

我意识到这是因为实际上更改了名称的“幽灵”DAG。似乎因为 DAG 在过去运行过（在 postgresDG 中有数据）并且在其他 DAG 中被引用为 child-DAG，引用旧名称的父 DAG 的触发器将“复活”旧的 DAG 名称，但是随着新代码。确实，旧的 DAG 名称和新的 DAG 代码不匹配，从而产生了“无限排队执行”的错误。

解决方案：

  1. 使用旧名称删除先前 DAG 运行的所有先前 DAG 运行
  2. 重新启动所有内容（网络服务器、工作线程、执行程序...）或删除相关 DAG（使用 UI 中的“删除 DAG”按钮）。

对该错误的解释可能会有所不同，但此修复程序对我的情况有效。

相关问题
最新问题