Apache Airflow 1.9性能下降求助：任务耗时远超终端运行

这种情况我之前也碰到过类似的，Airflow运行脚本比直接在终端跑慢很多，尤其是用LocalExecutor的时候，咱们可以从这几个方向排查：

1. 资源限制差异 #

Airflow的Worker进程可能有默认的CPU、内存限制，而终端直接运行时会使用系统全部可用资源。在Airflow 1.9的airflow.cfg配置文件里，检查这些关键参数：

• *worker_cpu_quota*：CPU配额限制
• *worker_memory_limit*：内存限制

如果这些值设置得比较保守，会导致Logstash无法获得足够资源来高效运行。你可以对比终端运行时的资源占用（用htop或top查看），调整Airflow的资源配置。另外，哪怕是极简的Airflow实例，调度进程本身也会占用少量资源，叠加起来可能影响Logstash的运行速度。

2. 环境变量不一致 #

Airflow Worker的运行环境和你的终端环境大概率不一样，比如Logstash依赖的*JAVA_HOME*、数据库连接变量、ElasticSearch配置变量等，可能在Airflow环境中未正确设置，导致Logstash启动或运行时额外耗时。

你可以在脚本开头添加一行：

env > /tmp/airflow_task_env.txt

然后在终端手动运行脚本时也执行：

env > /tmp/terminal_env.txt

对比两个文件，找出关键环境变量的差异，把缺失或不一致的变量在Airflow的任务配置中补充（比如在DAG的BashOperator里用env参数指定）。

3. 进程优先级问题 #

Airflow Worker进程的默认优先级可能比终端进程低，系统会给低优先级进程分配更少的CPU时间片。你可以用ps -l命令查看两种方式下Logstash进程的*NI*（nice值）：

• nice值越低，优先级越高（范围是-20到19）
• 如果Airflow运行的Logstash进程nice值更高（比如默认0，但有些系统会给服务进程默认更高的nice值），可以在脚本里添加：

renice -n -5 -p $$

提升当前脚本进程的优先级，看看是否能缩短运行时间。

4. Airflow日志IO的影响 #

Airflow会捕获任务的stdout和stderr并写入日志文件，如果Logstash运行时输出大量日志，磁盘IO操作会拖慢进程。你可以尝试把脚本的输出重定向到/dev/null：

your_logstash_start_command > /dev/null 2>&1

如果运行时间明显缩短，说明日志IO是瓶颈，可以调整Airflow的日志配置（比如改用更快的日志存储，或者减少Logstash的日志输出级别）。

另外，Airflow 1.9的LocalExecutor用子进程管理任务，虽然启动开销不大，但旧版本可能存在一些调度延迟的小问题，如果你有条件，也可以考虑升级到更高版本的Airflow（比如2.x）试试，但升级前一定要做好测试。

5. 数据库/ES连接的隐形差异 #

虽然脚本完全相同，但Airflow运行时的用户可能和终端用户不同，导致数据库或ElasticSearch的连接权限、方式有差异。比如：

• 数据库连接用了不同的认证方式，导致查询时额外耗时
• ES的连接超时参数在Airflow环境中未正确设置，导致重试次数增加

你可以在脚本中添加日志，记录Logstash的数据库查询耗时、ES写入耗时，对比两种运行方式下的时间差异，定位是哪个环节拖慢了速度。

内容的提问来源于stack exchange，提问作者Robin Diederen