当前位置：首页 > news >正文

Celery任务阻塞问题排查

news 来源：原创 2025/3/17 3:04:16

笔者在工作中经常用到Celery，遇到了2个任务阻塞的问题，分享经验如下。

1 Celery原理

Celery是基于Python开发的分布式任务调度框架，可以将任务发送到若干台机器上，实现多并发调度和计算。Celery的架构主要包含生产者（Producer）、消费者（Worker）、中间人（Broker）、任务结果（Backend）。

生产者一般是计算程序的入口，负责发送任务。

中间人一般是Rabbitmq消息队列或Redis，负责接收生产者发送的任务。

消费者中包含主要的算法业务逻辑，从中间人取走任务，执行相应计算任务，最后存到数据库中。

任务结果一般是Redis，保存消费者任务执行的结果，例如任务执行是否成功、任务执行时间等。

生产者通过任务结果获取任务执行状态，当所发送所有任务全部执行完毕，代表当前任务结束。

2 问题一排查

2.1 故障现象

Celery运行任务时卡住，表现在Flower里的Active一直不动（Flower是一个监控Celery任务执行情况的工具）。

并且消息队列里Unacked任务数一直不变。Unacked表示Worker未确认。

生产者也一直获取不到结果，导致跑批暂停。

2.2 排查过程

找到任务暂停的机器，使用docker logs XXX(XXX为docker名称)，发现报错如下

抛出的异常不是固定的，但都与数据库的连接池有关。因此分析的重点放在数据库连接池与Celery的结合使用上。

某worker卡住以后，其处理的任务会停留，且已经预取(prefetch)的任务也执行不下去。其他任务被其他worker卡住，因此表现出上述现象。flower中体现的是worker正在处理的任务卡住，消息队列中unacked体现的是预取的任务卡住。

2.3 故障分析

Celery默认使用多进程fork实现并发。例如并发度设置为4，则根据ps命令可以看到有1个父进程，4个子进程。在父进程fork出子进程时，会将数据库连接完整传给子进程。

数据库连接体现为文件描述符（file descriptors），一般文件描述符在不同进程之间应该是独立的。由于Celery的fork机制，导致多个子进程同时操作同一个文件描述符，进而导致数据库连接异常。

而且出现故障的任务执行很快，程序处理时间集中在读取数据库的步骤。因此在大量任务发送情况下，很容易造成fork出的4个子进程同时连接数据库现象，从而产生异常。这也说明此问题的发生是有概率的，程序中读取数据库的时间比重越大，出现问题的概率会增大。本例中其他worker没有出现问题，说明其fork出的4个子进程没有同时读取数据库。

2.4 解决方案

2.4.1 解决方案1：修改Celery并发模式

修改Celery启动命令中的并发模式，将--pool为threads、gevent、solo，分别代表多线程、协程、单机模式。Celery默认为多进程模式prefork。

优势：代码不需要改动

劣势：（1）线程和协程不适合计算密集型任务，但计算密集型任务恰恰是项目中耗时最久的任务；（2）多线程、协程方式无法配置worker_max_tasks_per_child，即无法避免内存溢出；（3）发现有重复计算问题；（4）Python存在GIL锁，多线程的效果将大打折扣。

2.4.2 解决方案2：修改Celery的并发度为1

Celery依然使用多进程启动，但修改并发度为1。从故障原因可知，父进程fork的子进程如果只有1个，则只有1个子进程操作文件描述符，避免冲突。

优势：代码不需要改动

劣势：运行速度较慢。若因为降低并发度而增大docker数量，由于docker本身也要占用内存、硬盘空间，会导致服务器性能压力较大。

2.4.3 解决方案3：数据库的连接池修改为空

在建立数据库连接时使用nullpool，即不建立连接池。

优势：完全避免不同worker之间的连接池互相影响。

劣势：单个worker每次取到新任务都要重新创建连接，无法从连接池中复用数据库连接

2.4.4 解决方案4：在定义数据库单例时即清除连接

劣势：如果在执行dispose之后、父进程fork子进程之前程序需要连接数据库（例如需要从数据库中获取相关单例），则父进程继承给子进程的连接依然非空，故障依然存在。

2.4.5 解决方案5：在Fork子进程时清除连接池（SQLAlchemy官方推荐方案）

官方建议子进程在启动时清除连接。可以使用Celery的signal功能，每次父进程fork出子进程时，将连接池中的连接清除，防止父进程中的连接继承到子进程中。此外由于只在fork子进程时做这样的操作，因此同一个worker子进程处理前后任务时，使用同一个连接池，即上一个任务使用的连接会留到下一个任务继续执行，直到此子进程被销毁，从而避免额外的开销。

2.4.6 解决方案6 比上一条更优美的解决方案

与上一条解决方案同样的思路，但是不必把所有连接显式地列出，而是在创建连接时，定义一个连接的基类，将所有实例化的连接存入到列表中。在Celery的signal处取此列表中所有的连接执行dispose。

3 问题二排查

3.1 故障现象

使用多进程模式启动Celery，生产者发送任务后，消费者接收到任务卡住。在消费者单机启动Python进程运行任务不会卡住，Celery使用多线程模式运行任务也不会卡住。

3.2 排查过程

查看Celery的进程，使用strace命令，查找当前任务卡在哪里。

如上图所示，ps查看Celery进程，共有5个进程。其中1个是父进程，其余4个进程是父进程fork出来的子进程，子进程是实际工作的进程。

对其中1个子进程执行strace，发现卡在futex这里。通过查找资料得知，Futex是一种用户态和内核态混合的同步机制，是一种轻量级的锁。

此外，在程序中打印日志，发现卡在读取数据库的步骤。

结合以上2部分线索可知，任务卡住与锁有关，与数据库有关。笔者突然想到在读取OceanBase数据库时使用了jar包，作为jdbc驱动的输入。读取jar包文件很有可能造成了锁。

3.3 事件还原

由于笔者是Python开发人员，对系统底层逻辑不熟悉，猜测的具体过程如下：

在启动Celery时，在本项目业务场景下，父进程需要从数据库读取相关数据，使用了jar包。主进程在读取时加了锁且未将锁释放，而当fork出4个子进程时，将未释放锁的文件同时复制给子进程，导致子进程一直在等待获取锁，最终表现为程序卡住。

在主进程中将读取数据库的代码注释掉后，worker正常执行。

3.4 解决方案

3.4.1 解决方案1：Celery使用多线程模式

与上一项目类似，解决方案也可以选择在Celery启动时使用多线程模式，但其优劣势在上一项目中已有说明，并不合适。

3.4.2 解决方案2：Celery的多进程改成用spawn模式

通过查找资料，在遇到Python多进程卡住时，可以将多进程模式切换成spawn模式解决，原因是spawn启动的子进程是新的python解释器，而不是从父进程中完全复制。

Celery中与spawn模式相关的配置是CELERYD_FORCE_EXECV，在旧版本中可以配置，但在后来的版本中已不建议配置，在新版本中甚至删掉了此配置。如果强行换成旧的版本，不仅会造成适配上的问题，更可能会复现官网所说的潜在问题。

如上图所示，官网在3.1.17版本提示不要启用此配置，在5.0版本中移除此配置。

3.4.3 解决方案3：在主进程中不再读取OceanBase数据库（最终的解决方案）

通过梳理业务逻辑，在主进程中，读取OceanBase数据库主要是为了获取部分配置数据。但实际上这部分配置数据是常量，因此直接在代码中定义好，不再从数据库中获取。

修改以后，worker成功执行，不再卡住。

4 经验总结

以上2个问题都遇到了Celery任务卡住的问题，其原因十分类似，但具体细节又不相同。它们都是在多进程模式下产生的，问题1是因为子进程之间数据库连接池的冲突，问题2是因为子进程之间数据库驱动文件的冲突。

Celery中多进程只支持fork，不支持spawn，因此使用多进程非常容易导致任务卡住。在解决此类问题时，一方面在代码中多打些日志，具体定位程序在哪里卡住，另一方面使用strace等命令，查看程序最后一次进行调用的资源。

5 参考资料

Connection Pooling — SQLAlchemy 2.0 Documentation

https://celeryproject.readthedocs.io/zh-cn/latest/history/whatsnew-4.0.html?highlight=CELERYD_FORCE_EXECV%20#features-removed-for-lack-of-funding

https://celeryproject.readthedocs.io/zh-cn/latest/history/changelog-3.1.html?highlight=CELERYD_FORCE_EXECV%20#version-3-1-17

https://github.com/celery/celery/issues/6036

https://devpress.csdn.net/cloudnative/66d58c512045de334a5698fe.html