Airflow2.1.2 GUI运行示例DAG耗时久且DagFileProcessorManager心跳报错如何解决

差异说明 #

Airflow命令行执行airflow test时直接启动单进程运行任务，不会经过调度器的DAG文件扫描、解析流程，不触发DagFileProcessorManager的心跳检测逻辑，因此不会出现卡顿问题；从GUI触发的DAG运行需要调度器全程参与DAG状态更新、任务调度，所以会暴露调度器侧的异常。

排查思路 #

• 检查DAG目录文件规模：Airflow 2.1.2版本的DagFileProcessorManager默认会全量扫描dags目录下所有文件，如果目录中存在大量无关文件（临时文件、.pyc缓存、非DAG的Python脚本、数据文件等），会导致单次扫描耗时超过默认60秒的超时阈值，触发心跳超时重启。可先统计dags目录下的文件总数，清理无关文件后重试验证。
• 检查调度器配置项：查看airflow.cfg中以下核心配置的取值：
  • dag_dir_list_interval：DAG目录扫描间隔，默认30秒，配置过小会导致频繁扫描占用资源
  • dag_file_processor_timeout：DAG文件处理器超时时间，默认60秒，扫描耗时长时会被误杀
  • parsing_processes：DAG解析进程数，默认2，DAG数量较多时会出现解析能力不足
• 检查DAG文件代码规范：如果DAG文件的全局作用域存在耗时逻辑（比如导入阶段发起外部请求、读取大文件、执行复杂计算等），每次DAG扫描都会执行这部分代码，拉低整体扫描效率，阻塞心跳上报。可通过airflow dags list-import-errors命令查看是否存在DAG导入耗时过长或报错的记录。
• 检查节点资源占用：调度器所在节点的CPU、内存、磁盘IO占用过高时，会导致DagFileProcessorManager进程无法及时得到系统调度，无法按时上报心跳触发重启。可通过top、iostat等命令观测调度器运行时的资源占用情况。

修复方案 #

• 清理DAG目录：删除dags目录下的非业务必需文件，仅保留DAG定义文件和必要的工具依赖脚本，缩小扫描范围。
• 优化DAG代码：所有耗时逻辑都放到Operator的执行方法内部，禁止在DAG全局作用域执行耗时操作、外部请求、大文件读取等逻辑，降低DAG解析阶段的耗时。
• 调整调度器适配配置：

# 延长DAG文件处理器超时时间，避免正常扫描被误杀
dag_file_processor_timeout = 120
# 适当调大解析进程数，建议取值不超过节点CPU核心数的1/2
parsing_processes = 4
# 拉长DAG目录扫描间隔，减少频繁扫描的性能开销
dag_dir_list_interval = 60

• 升级稳定小版本：Airflow 2.1.2存在多个DAG解析相关的已知Bug，上述调整无效时可升级到同分支的2.1.4版本，该版本修复了多个DagFileProcessorManager心跳误判、解析效率低的问题。

内容的提问来源于stack exchange，提问作者Rick Giuly