Celery Worker停止执行并持续打印相同日志该如何排查解决

云原生阿岚

2026-9-28

故障原因分析

进程架构配置错误：启动命令中携带-B参数会将Celery Beat定时调度器与Worker任务执行进程合并到同一个进程实例运行，同时你指定的-P solo单进程执行池会让--concurrency=10的并发配置完全失效，所有任务只能在单进程内串行执行。大文件处理任务会长期占用单进程资源，要么直接阻塞Beat调度逻辑，要么Worker进程崩溃后仅剩下Beat线程存活，因此你只能看到Beat的调度日志，看不到Worker的任务执行相关输出。
大文件解析触发内存溢出：小文件处理正常、大文件执行中断，核心原因大概率是XML解析逻辑采用了DOM类全量加载方案，一次性将9GB文件全部载入内存处理，XML文件加载到内存后数据体积会膨胀数倍到数十倍，超出Docker容器的内存限制后被系统OOM Killer强制终止进程，进程被强制 kill 时来不及输出异常栈，因此没有错误日志留存。
Redis Broker任务可见性超时：Redis作为Celery Broker的默认visibility_timeout为3600秒（1小时），如果大文件处理任务单次执行时长超过1小时，Redis会判定对应Worker失联，将任务重新放回队列，也会引发任务执行中断、状态异常的问题。

修复方案

拆分Celery Beat与Worker进程：生产环境禁止在Worker启动命令中加-B参数，将Beat和Worker拆分为两个独立的Docker容器部署，避免进程间互相干扰。
调整后的Worker启动命令：
```
CMD [ "celery", "-A", "worker.celery", "worker", "--loglevel=debug", "--concurrency=4", "-P", "prefork", "-n", "%h" ]
```
独立Beat容器的启动命令：
```
CMD [ "celery", "-A", "worker.celery", "beat", "--loglevel=debug" ]
```
注意solo池仅适合本地调试使用，生产环境改用prefork/gevent池即可，并发数根据容器分配的CPU核心数设置，不要超过核心数的2倍。
优化XML解析逻辑：放弃全量加载的DOM解析方案，改用Python自带的xml.sax或者iterparse流式解析接口，边读取文件边解析边写入数据库，全程仅保留当前解析节点的内容在内存，避免全量加载大文件导致内存溢出。
调整Redis超时配置：在Celery配置项中新增broker_transport_options参数，根据大任务的最长预估执行时间调整visibility_timeout，比如设置为12小时：
```
broker_transport_options = {
    'visibility_timeout': 43200  # 单位为秒
}
```
增加异常排查手段：执行docker inspect <故障Worker容器ID> | grep OOMKilled可直接确认进程是否因内存溢出被系统终止，同时将Celery日志输出到持久化存储，避免进程崩溃时日志丢失。

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