我们正在试验Apache Airflow（版本1.10rc2，使用python 2.7），并将其部署到kubernetes，Web服务器和调度程序到不同的Pod，并且数据库也使用了Cloud sql，但是我们一直面临内存不足的问题与调度程序窗格。
在OOM时刻，我们仅运行了4个示例Dag（约20个任务）。主机的内存为1Gib。我在其他文章中已经看到，一个任务在运行时可能会消耗大约50Mib的内存，并且所有任务操作都在内存中，没有任何内容刷新到磁盘上，因此已经可以提供1Gb的内存。
是否有任何经验法则可用于计算基于并行任务的调度程序需要多少内存？
除了降低并行度之外，是否还有其他调整可以减少调度程序本身中的内存使用？
我认为我们的用例不需要Dask或Celery用更多的机器为工人水平扩展气流。
有关配置的更多详细信息：
executor = Localexecutor
parallelism = 10
dag_concurrency = 5
max_active_runs_per_dag = 2
workers = 1
worker_concurrency = 16
min_file_process_interval = 1
min_file_parsing_loop_time = 5
dag_dir_list_interval = 30
当时运行的dag是example_bash_operator，example_branch_operator，example_python_operator和我们开发的一个quickDag。
在某些情况下，所有这些仅具有简单的任务/运算符，例如DummyOperators，BranchOperatos，BashOperators，但仅执行echo或sleep，而PythonOperators也执行睡眠。总共大约要执行40个任务，但并非所有任务都是并行运行的，因为其中一些任务是下游的，依赖等，并且我们的并行度设置为10，如上所述只有一个工人，并且{{ 1}}设置为5。
我在气流日志中看不到任何异常，在任务日志中也看不到任何异常。
仅运行这些dag之一，似乎气流正在相应地起作用。
我可以在调度程序窗格中看到许多调度程序进程，每个进程使用0.2％或更多的内存：
dag_concurrency
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
这是使用0.3％的内存运行的任务之一：
461384 airflow 20 0 836700 127212 23908 S 36.5 0.4 0:01.19 /usr/bin/python /usr/bin/airflow scheduler 461397 airflow 20 0 356168 86320 5044 R 14.0 0.3 0:00.42 /usr/bin/python /usr/bin/airflow scheduler 44 airflow 20 0 335920 71700 10600 S 28.9 0.2 403:32.05 /usr/bin/python /usr/bin/airflow scheduler 56 airflow 20 0 330548 59164 3524 S 0.0 0.2 0:00.02
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
答案 0 :(得分：0)
实际上并没有一个简单的经验法则，因为它可能因您的工作流程而有很大差异。
如您所见，调度程序将创建多个派生进程。同样，每个任务（虚拟对象除外）都将在其自己的进程中运行。取决于操作员和所处理的数据，每个任务所需的内存量可能会发生巨大变化。
并行性设置将直接限制所有dag运行/任务中同时运行的任务数量，这对于使用LocalExecutor的用户将产生最大的影响。您也可以尝试将max_threads下的[scheduler]设置为1。
因此，（非常）普遍的经验法则是善待资源：
[256 for scheduler itself] + ( [parallelism] * (100MB + [size of data you'll process]) )
数据的大小将需要更改，具体取决于您是加载完整的数据集，还是在任务执行过程中对其进行处理。
即使您认为不需要扩展集群，我仍然建议您使用CeleryExecutor，即使只是将调度程序和任务彼此隔离。这样一来，如果您的调度员或芹菜工人去世，那么两者都不会掉下来。特别是在k8中运行，如果您的调度程序执行sigterm，它将与所有正在运行的任务一起杀死它。如果在不同的Pod中运行它们，并且调度程序Pod重新启动，则您可以连续完成任务。如果您有更多的工作人员，它将减少其他任务对内存/处理峰值的影响。