Airflow 内存不足问题

我们正在试验Apache Airflow（版本1.10rc2，使用python 2.7），并将其部署到kubernetes、Web服务器和调度程序的不同pod中，数据库也在使用云sql，但调度程序pod一直面临内存不足的问题

在OOM的时候，我们只运行了4个示例DAG（大约20个任务）。pod的内存为1GB。我在其他文章中看到，一个任务在运行时可能会消耗大约50MB的内存，并且所有任务操作都在内存中，没有任何内容被刷新到磁盘，因此已经有1Gb的内存了

有没有什么经验法则可以用来计算基于并行任务的调度器需要多少内存

除了降低并行性之外，是否还有任何调整可以用来减少调度程序本身内存的使用

我不认为我们的用例需要Dask或芹菜来水平调节气流，为工人提供更多的机器

关于本次对话，请再多了解一些细节：

executor=Localexecutor

parallelism=10

dag\u并发=5

max\u active\u runs\u per\u dag=2

workers=1

worker\u并发性=16

min\u file\u process\u interval=1

min\u file\u parsing\u loop\u time=5

dag\u dir\u list\u interval=30

当时运行的DAG是example_bash_操作符、example_branch_操作符、example_python_操作符和我们开发的一个quickDag

它们都只是简单的任务/操作符，比如DummyOperators、BranchOperatos、BashOperators（在某些情况下），但只执行echo或sleep，而PythonOperators也只执行sleep。总共大约有40个任务，但并不是所有任务都并行运行，因为其中一些任务是下游任务、从属任务等，我们的并行度设置为10，只有一个工作进程，如上所述，

dag\u并发性

设置为5

我在气流日志和任务日志中都看不到任何异常

仅运行其中一个DAG，气流似乎也在相应地工作

我可以在调度程序盒中看到许多调度程序进程，每个进程使用0.2%或更多的内存：

PID用户PR NI VIRT RES SHR S%CPU%MEM TIME+命令

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 0 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/usr/bin/airflow scheduler 56 airflow 20 0 330548 59164 3524 S 0.00.2 0:00.02

这是使用0.3%内存运行的任务之一：

PID用户PR NI VIRT RES SHR S%CPU%MEM TIME+命令

---

462042 airflow 20 0 282632 91120 10544 S 1.7 0.3 0:02.66/usr/bin/python/usr/bin/airflow run example_bash_operator runme_1 2018-08-29T07:39:48.193735+00:00——local-sd/usr/lib/python2.7/site packages/apache_airflow-1.10.0-py2.7.7.egg/airflow/example_dags/example_-example_-bashïïïïïïïïï因为它可以根据您的工作流程变化很大

如您所见，调度程序将创建几个fork进程。此外，每个任务（虚拟任务除外）都将在其自己的进程中运行。根据操作员和处理的数据，每个任务所需的内存量可能会有很大差异

并行度设置将直接限制在所有dag运行/任务中同时运行的任务数量，这将对使用LocalExecutor的用户产生最显著的影响。您还可以尝试将
[scheduler]
下的
最大线程数设置为1

因此，一个（非常）普遍的经验法则是善待资源：

[256 for scheduler itself] + ( [parallelism] * (100MB + [size of data you'll process]) )

其中，数据大小需要根据您是加载完整的数据集，还是在任务执行过程中处理数据块而改变

即使您认为不需要扩展集群，我仍然建议使用CeleryExecutor，哪怕只是将调度程序和任务彼此隔离。这样，如果您的调度程序或芹菜工人死亡，它不会同时关闭这两个。特别是在k8中运行时，如果您的调度程序停止运行，它将与任何正在运行的任务一起终止它。如果您在不同的pod中运行它们，并且调度程序pod重新启动，那么您可以不间断地完成任务。如果您有更多的工作人员，这将减少其他任务造成的内存/处理峰值的影响。
您可以编辑您的问题并添加oom日志吗？哪些任务何时运行多长时间？这些任务是做什么的？什么时候开始？需要多长时间？请回答您的问题并将评论整合到其中。您能发布完整的顶部吗？另外，pod上请求的内存是多少？k8节点有多少内存，气流吊舱正在运行？吊舱请求增加到1.2Gib，我们增加了内存，吊舱现在似乎稳定了。实际上，我的问题是，在确定气流装置的尺寸时，是否有任何经验法则可以遵循，我想这是一个很难回答的问题，1GB无论如何都不足以运行我们正在运行的那些测试任务。我们已经将限制提高到4Gib，初始请求设置为1Gib，但我相信，一旦我们增加并行运行的DAG/任务的数量，我们可能需要重新考虑这些限制。