Airbnb Airflow使用所有系统资源

Question

我们使用LocalExecutor为我们的ETL设置了Airbnb / Apache Airflow，当我们开始构建更复杂的DAG时，我们注意到Airflow已经开始使用大量的系统资源。这对我们来说是令人惊讶的，因为我们主要使用Airflow来协调在其他服务器上发生的任务，因此Airflow DAG花费大部分时间等待它们完成 - 在本地没有实际执行。

最大的问题是Airflow似乎在任何时候都占用了100％的CPU（在AWS t2.medium上），并使用超过2GB的内存和默认的airflow.cfg设置。

如果相关，我们使用docker-compose运行容器两次运行Airflow;一次为scheduler，一次为webserver。

我们在这里做错了什么？这是正常的吗？

修改 这是来自htop的输出，按使用的％Memory排序（因为这似乎是现在的主要问题，我的CPU下降了）：

我认为理论上我可以减少gunicorn工作者的数量（它默认为4），但我不确定所有/usr/bin/dockerd进程是什么。如果Docker使事情变得复杂，我可以删除它，但它使部署变更非常容易，如果可能的话我宁愿不删除它。

Answer 1

我还尽一切努力降低CPU使用率，而Matthew Housley关于MIN_FILE_PROCESS_INTERVAL的建议正是解决之道。

至少直到气流1.10出现...然后CPU使用率再次上升。

这就是我需要做的所有事情，以使气流在具有2gb ram和1 vcpu的标准数字海洋小滴上正常工作：

1。计划程序文件处理

防止气流一直被重新加载，并进行以下设置： AIRFLOW__SCHEDULER__MIN_FILE_PROCESS_INTERVAL=60

2。修复airflow 1.10调度程序错误

气流1.10中的AIRFLOW-2895错误导致CPU负载过高，因为调度程序不断循环而不中断。

它已经在master中修复，并有望被包含在airflow 1.10.1中，但可能要花几周或几个月才能发布。同时，此补丁解决了该问题：

--- jobs.py.orig    2018-09-08 15:55:03.448834310 +0000
+++ jobs.py     2018-09-08 15:57:02.847751035 +0000
@@ -564,6 +564,7 @@

         self.num_runs = num_runs
         self.run_duration = run_duration
+        self._processor_poll_interval = 1.0

         self.do_pickle = do_pickle
         super(SchedulerJob, self).__init__(*args, **kwargs)
@@ -1724,6 +1725,8 @@
             loop_end_time = time.time()
             self.log.debug("Ran scheduling loop in %.2f seconds",
                            loop_end_time - loop_start_time)
+            self.log.debug("Sleeping for %.2f seconds", self._processor_poll_interval)
+            time.sleep(self._processor_poll_interval)

             # Exit early for a test mode
             if processor_manager.max_runs_reached():

将其应用于patch -d /usr/local/lib/python3.6/site-packages/airflow/ < af_1.10_high_cpu.patch;

3。 RBAC Web服务器的CPU高负载

如果您升级为使用新的RBAC Web服务器UI，您可能还会注意到该Web服务器持续使用大量CPU。

由于某种原因，RBAC接口在启动时会占用大量CPU。如果您在功率较低的服务器上运行，则可能会导致网络服务器启动非常缓慢，并导致CPU使用率永久升高。

我已将此错误记录为AIRFLOW-3037。要解决它，您可以调整配置：

AIRFLOW__WEBSERVER__WORKERS=2 # 2 * NUM_CPU_CORES + 1
AIRFLOW__WEBSERVER__WORKER_REFRESH_INTERVAL=1800 # Restart workers every 30min instead of 30seconds
AIRFLOW__WEBSERVER__WEB_SERVER_WORKER_TIMEOUT=300 #Kill workers if they don't start within 5min instead of 2min

通过所有这些调整，我的气流在空闲时间仅使用了1％vcpu和2gb ram的数字海洋标准液滴上的CPU使用量很小。

Answer 2

我刚遇到这样的问题。在t2.xlarge实例中，Airflow大约消耗了一个完整的vCPU，其中绝大部分来自调度程序容器。检查调度程序日志，我可以看到它每秒处理我的单个DAG超过一次，即使它每天只运行一次。我发现MIN_FILE_PROCESS_INTERVAL被设置为默认值0，因此调度程序正在循环遍历DAG。我将进程间隔更改为65秒，而Airflow现在在t2.medium实例中使用的vCPU不到10％。

Answer 3

尝试更改airflow.cfg中的以下配置

# after how much time a new DAGs should be picked up from the filesystem
min_file_process_interval = 0

# How many seconds to wait between file-parsing loops to prevent the logs from being spammed.
min_file_parsing_loop_time = 1

Answer 4

关键是如何处理 dag 文件。 将 8 核服务器上调度程序的 CPU 使用率从 80%+ 减少到 30%，我更新了 2 个配置键，

min_file_process_interval from 0 to 60.
max_threads from 1000 to 50. 

Answer 5

对于初学者，您可以使用htop来监控和调试CPU使用情况。

我建议你在同一个docker容器上运行webserver和scheduler进程，这会减少在ec2 t2.medium上运行两个容器所需的资源。 Airflow worker需要资源来下载数据并在内存中读取数据，但webserver和scheduler是非常轻量级的流程。确保在运行Web服务器时，您使用cli控制在实例上运行的工作器数量。

airflow webserver [-h] [-p PORT] [-w WORKERS]
                         [-k {sync,eventlet,gevent,tornado}]
                         [-t WORKER_TIMEOUT] [-hn HOSTNAME] [--pid [PID]] [-D]
                         [--stdout STDOUT] [--stderr STDERR]
                         [-A ACCESS_LOGFILE] [-E ERROR_LOGFILE] [-l LOG_FILE]
                         [-d]

Answer 6

我在EKS上部署气流时也遇到了同样的问题，可以通过在气流配置中将max_threads更新为128来解决。

max_threads：调度程序将并行产生多个线程来调度dag。这是由max_threads控制的，默认值为2。用户应在生产环境中将此值增加到更大的值（例如，调度程序在其中运行的cpus数-1）。

从这里 https://airflow.apache.org/docs/stable/faq.html

Answer 7

我尝试在AWS t2.micro实例（1vcpu，1gb内存，适用于免费套餐）上运行Airflow，并且遇到了同样的问题：工作人员消耗了100％的cpu并消耗了所有可用内存。

EC2实例完全卡住并且无法使用，当然Airflow无法正常工作。

因此，我使用here中描述的方法创建了一个4GB的交换文件。通过交换，不再有任何问题，Airflow完全正常运行。 当然，只有一个vcpu，您不能指望令人惊叹的性能，但是它可以运行。