Docker Compose部署Airflow集群时内存限制引发崩溃问题咨询

不会。
CeleryExecutor分布式架构的职责完全拆分：Airflow主节点仅承载调度器、WebUI、元数据库等调度管控组件，只负责任务的分发、状态同步，不参与任何任务的实际执行。工作节点上的Celery Worker进程仅负责从消息队列拉取任务指令，调用本地Docker daemon启动独立的任务容器，任务容器的资源配额完全由工作节点的本地配置、Docker daemon配置、任务启动参数决定，和主节点的硬件资源、内存限制没有任何关联。如果主节点内存不足，只会引发主节点自身组件崩溃、调度延迟等问题，不会限制工作节点上任务的内存上限。

• 检查工作节点上Celery Worker自身的资源限制：如果Celery Worker是容器化部署的，先确认Worker容器是否配置了内存上限，Worker进程如果触发OOM，会连带它启动的任务容器一起被销毁，表现为任务异常崩溃。
• 检查任务挂载卷的类型：如果写入数据的挂载盘配置为tmpfs（内存文件系统），写入的所有数据都会被计入容器的内存占用，你直接手动启动容器时如果挂载的是本地磁盘，就不会出现内存占用过高的问题，可通过docker inspect 任务容器ID查看Mounts字段的类型确认。
• 检查Docker daemon的全局默认资源限制：查看/etc/docker/daemon.json中的default-ulimit、default-shm-size等全局配置，是否设置了全局内存/共享内存上限，该限制会覆盖部分容器启动参数，另外可检查宿主机的cgroup配置，是否给Docker服务设置了全局内存配额。
• 核对DockerOperator的启动参数和你手动启动容器的参数差异：对比docker inspect手动启动的正常容器和Airflow启动的异常容器的配置差异，重点看ShmSize、Ulimits、CgroupParent等资源相关配置，确认是否有遗漏的参数未在DockerOperator中配置。
• 查看OOM kill的具体日志：执行dmesg | grep -i oom查看系统OOM日志，确认被kill的进程是任务容器内的业务进程、Celery Worker进程还是其他进程，明确OOM触发的主体。
• 检查工作节点的任务并发配置：确认Celery Worker的worker_concurrency参数是否设置过高，多个任务同时运行时总内存占用超过宿主机的阈值触发OOM，即便单个任务的内存没有达到上限。
• 检查任务日志传输配置：如果任务配置了将容器内日志实时同步回Airflow主节点，确认是否开启了日志的本地缓存，大量日志在Worker端缓存时会占用额外内存，触发工作节点的OOM。

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