Airflow v1.9.0中某DAG长时间运行阻塞其他DAG启动问题求助

结合你提供的所有信息，我来帮你拆解Airflow v1.9.0里matching DAG阻塞其他任务的问题，以及对应的排查和解决方向：

核心原因：LocalExecutor的并行资源被独占 #

从任务日志里能看到你的Airflow用的是LocalExecutor——这个执行器靠进程池来同时运行多个任务。如果你的配置里全局并行度或者默认任务池的槽位被设为1，那matching启动后就会占满唯一的执行资源，其他所有DAG的任务只能排队等它结束。

排查与修复步骤： #

• 打开airflow.cfg检查关键参数：
  • parallelism：全局最大并行任务数，默认是32，但如果被改成1就会导致单任务串行执行。建议根据服务器CPU核数调整（比如8核服务器设为8-16）。
  • dag_concurrency：单个DAG的最大并行任务数，确保这个值不是1。
• 检查默认任务池的槽位数量：
  用SQL查询Airflow数据库：

  SELECT pool, slots FROM pool WHERE pool='default';
  

  如果slots是1，把它改成更大的值（比如10）；或者给matching任务单独分配专属池：
  在SSHOperator的代码里添加pool='matching_pool'，然后在Airflow UI的「Admin → Pools」里创建这个池，设置slots=1。这样matching只会占用自己池的1个槽位，其他任务用默认池的资源，就不会被阻塞了。

其他可能的影响因素 #

1. depends_on_past=True的限制 #

你的matching DAG设置了depends_on_past=True，这会让当前任务必须等上一个执行实例成功才能启动，所以它不会同时跑多个自身的实例，但这个设置只会限制matching自己的并行，不会直接阻塞其他DAG，不是核心问题。

2. 老版本Airflow的已知bug #

Airflow v1.9.0是2018年的老旧版本，存在不少调度器和执行器的bug——比如任务状态更新不及时、资源分配逻辑不完善，这些都可能导致调度器误判所有资源被占用，从而不启动其他任务。

修复建议：

如果条件允许，优先升级到Airflow 2.x系列的稳定版本，新版本不仅修复了大量旧bug，还提供了更完善的资源管理和调度能力。

优化matching任务本身（从根源减少阻塞时间） #

既然每月大数据导入时任务会跑7小时，你可以优化远程的run_nightly_matching.sh对应的Python脚本：

• 检查数据库查询是否可以优化（比如添加合适的索引、分批次处理数据）
• 给数据库连接添加合理的超时和重试机制，避免长时间无效占用连接
• 如果可能，把大任务拆分成多个小任务并行执行，减少单任务占用资源的时长

最后，你可以先运行airflow config list查看当前的并行度配置，确认是否存在资源限制的问题；下次大数据导入时，也可以在Airflow UI里观察任务池的使用情况，验证资源是否被耗尽。

内容的提问来源于stack exchange，提问作者Kate R.