当有大量任务时，Airflow scheduler不会安排（或缓慢安排）

我正在Google Cloud Composer（版本：Composer-1.10.2-airflow-1.10.6）上使用airflow

我意识到当有很多任务要处理时，调度器不会安排任务（参见下面的甘特图）

（不要注意颜色，红色任务是“createTable操作符”，如果表已经存在，则会失败，因此在DAG的下一部分（重要部分）运行之前，它们必须失败5次）

任务之间存在时间间隔！（例如，上午10点到下午15点之间有5个小时，但什么也没有发生）

通常情况下，它可以使用约40个DAG，每个DAG大约有100-200个任务（有时会多一点）。但最近我添加了2个DAG，每个DAG有很多任务（每个任务约5000个），并且调度程序非常慢，或者无法调度任务。 在屏幕截图上，我在下午15点暂停了2个DAG，执行了大量任务，调度程序又回来了，工作正常

你有什么解决办法吗？

气流是用来处理“无限量”任务的工具

以下是有关我的环境的一些信息：

• 版本：composer-1.10.2-airflow-1.10.6
• 群集大小：6（12vCPU，96GB内存）

以下是有关气流配置的一些信息：

谢谢你的帮助

编辑：

我的26个DAG是由一个.py文件通过解析一个巨大的JSON变量来创建所有DAG和任务而创建的

也许问题就出在这一点上，因为今天Airflow正在调度来自其他DAG的任务，而不是我所描述的26个DAG（特别是2个大DAG）。 更准确地说，Airflow有时会安排我的26个DAG的任务，但它安排其他DAG的任务更容易、更频繁。

我觉得你应该编写版本1.10.4，拥有最新的补丁总是有帮助的

---

你在用什么数据库？拥有所有这些失败的任务是非常不明智的。如果不存在，是否可以使用

创建表…

？

高任务间延迟通常表明存在与调度程序相关的瓶颈（与工作人员相关的瓶颈相反）。即使一次又一次地运行相同的DAG，Composer环境仍然可能遇到这样的性能瓶颈，因为每次工作的分布可能不同，或者后台可能运行不同的进程

首先，我建议增加调度程序可用的线程数（

scheduler.max_threads

），然后确保调度程序没有占用它所在节点的所有CPU。通过确定调度程序所在的节点的位置，然后在云控制台中进行检查，您可以检查该节点的CPU指标。要查找节点名称，请执行以下操作：

# Obtain the Composer namespace name
kubectl get namespaces | grep composer

# Check for the scheduler
kubectl get pods -n $NAMESPACE -o wide | grep scheduler

---

如果上述方法没有帮助，那么调度程序也可能是故意在某个条件下阻塞的。要检查计划程序检查要运行的任务时评估的所有条件，请设置

core.logging\u level=DEBUG

。在调度程序日志（您可以在云中过滤日志记录）中，您可以检查通过或失败的所有条件，以便任务运行或保持排队。

集群的运行状况如何？您是否注意到内存、处理中存在一些问题？我的群集似乎运行正常。我没有注意到任何奇怪的事情。你能检查一下你的项目的配额吗？配额安排一切正常。我认为问题不在于此，因为tothing（根本！）计划了很长一段时间。好吧，升级总是更好。对于“创建表”，我理解您的观点，我肯定会改变这一点（但这不是这里的问题）；我正在使用airflow的本机BigQueryCreateEmptyTableOperator，它负责所有这些失败。如果我正确理解创建表的每个任务，它将运行5次，这将极大地浪费资源。我知道这不是本例中的确切问题，但删除每个表的这4个任务将导致任务大大减少。当您同时处理多个DAG时，所有正在运行的任务都会有所帮助，即使在这之后可能需要采取另一个步骤。我建议您将

retries=0

添加到这些任务中，或者使用默认的BigQueryOperator重新创建任务，如果不存在完整的

CREATE TABLE…

命令，这很耗时，但可能是值得的。我完全理解不必担心。一些精确性：-我不理解为什么本机BigQueryCreateEmptyTableOperator没有处理这个问题，但是无论如何，-retries=0将在任务失败而没有第一次创建表的情况下中断DAG。但我同意你的看法。无论如何，这不是这里的主题：）我同意这不是主题，但试图解决主题而不解决多个不必要的任务也不是最好的前进方式。是的，你是对的，BigQueryCreateEmptyTableOperator应该能够以本机方式处理这个问题！按照你的建议，我改变了恼人的失败任务！这确实是更好的CPU使用率似乎也不错。我多次更改了调度程序的max_线程，但它没有做任何我相信的事情。目前，我有4个线程，因为我的节点中有2个虚拟核心。还有一件事。我有一个.py文件动态生成的26个DAG。我将其拆分为26.py文件（每个文件1个DAG），调度程序的响应似乎更好

# Obtain the Composer namespace name
kubectl get namespaces | grep composer

# Check for the scheduler
kubectl get pods -n $NAMESPACE -o wide | grep scheduler