Celery编排进程间歇性挂起问题排查求助

• 架构：Celery编排主应用 + Celery Worker，使用Docker化的RabbitMQ作为消息中间件（Broker）、Redis作为结果后端（Backend），所有服务运行在同一台机器上；主应用与Worker均通过systemd系统服务托管并监控。
• 业务逻辑：程序循环执行，每次迭代分发2万余个分片任务（会跳过已在运行的任务），核心代码片段如下：

chunk_args = (
    (asset, tc, pc) for tc, pc in itertools.product(time_chunks, pos_chunks)
)

pipe = func.chunks(chunk_args, settings.NUM_PROCESSES).group()

logger.warn("Sending pipe")
val = pipe.apply_async()
logger.warn(f"Pipe sent {val}")

return val

异常表现 #

编排进程间歇性无响应，挂起时长1-2分钟，挂起触发点集中在两个阶段：

1. 打印Sending pipe之后、Pipe sent之前
2. 打印Pipe sent之后

已完成的排查动作 #

• 挂起期间执行docker exec rabbitmq rabbitmqctl list_queues，确认RabbitMQ队列为空
• 通过htop观察，进程无高负载，内存占用始终低于30GB
• 使用py-spy对主进程做性能分析，未发现异常（推测线程处于空闲或休眠状态）
• 查看docker logs rabbitmq，无特殊异常日志

机器配置 #

128GB内存、32核Ryzen 5处理器、80TB硬件RAID1（btrfs格式）、2块250GB SSD组成软件RAID1（含60GB交换分区、170GB根分区）

1. 还有哪些排查工具可用？
2. 可能的原因是什么？
3. systemd是否会偶尔暂停繁忙进程？

一、可用排查工具 #

• strace/ltrace：挂起时执行strace -p <主进程PID>跟踪系统调用，定位是否卡在网络IO、文件IO或锁等待；用ltrace -p <主进程PID>查看Python库调用的阻塞点
• tcpdump：抓取主应用与RabbitMQ之间的网络包，排查TCP连接异常、延迟或丢包情况
• Celery内置工具：
  • 启用Celery Flower监控任务分发流程、Broker连接状态
  • 执行celery inspect stats/celery inspect active实时查看Worker的运行状态
• Redis监控：通过redis-cli info stats查看Redis的连接数、命令执行延迟，排查结果后端是否存在阻塞
• systemd详细日志：执行journalctl -u <服务名> -o verbose查看进程状态变化、资源限制触发的细节日志
• IO/内存监控：挂起期间用vmstat 1或iostat 1持续监控，检查是否有页交换（swapin/swapout）或磁盘IO延迟
• btrfs文件系统监控：执行btrfs filesystem df /检查磁盘空间，btrfs scrub status /查看文件系统健康状态，排查btrfs后台操作（平衡、scrub）导致的IO阻塞

二、可能的原因 #

• RabbitMQ流控或连接阻塞：虽然队列空，但RabbitMQ可能因瞬时负载触发流控（可通过rabbitmqctl status查看流控指标）；或者主应用的RabbitMQ连接池耗尽，导致发布消息时阻塞
• Redis结果后端阻塞：apply_async执行后Celery会与Redis交互记录任务状态，若Redis存在慢查询、连接超时，或主应用的Redis连接池配置不合理，可能引发阻塞
• Celery内部逻辑瓶颈：chunks.group()的内部线程锁竞争、任务ID生成或状态存储的串行处理，在分发大量任务时可能出现阻塞
• 瞬时磁盘IO阻塞：btrfs的后台平衡、scrub操作，或RAID的IO同步过程，可能导致短暂的磁盘IO延迟，影响主进程的日志写入或配置读取
• 生成器潜在阻塞：chunk_args为生成器，若asset、time_chunks或pos_chunks的生成逻辑存在隐藏延迟，可能导致任务分发前的阻塞
• Python GIL竞争：虽然CPU负载低，但大量任务分发时的线程切换可能引发GIL竞争，导致进程短暂挂起

三、systemd是否会暂停繁忙进程？ #

默认情况下，systemd不会主动暂停繁忙进程，仅在以下场景会干预：

1. 配置了资源控制参数（如MemoryMax、CPUQuota）且进程触发限制，此时进程会被限流而非暂停
2. 系统触发内存不足（OOM），systemd的OOM killer会终止进程而非暂停

结合你的情况，内存占用远低于阈值，且进程是挂起而非终止，因此systemd导致暂停的可能性极低。若需确认，可执行journalctl -k | grep OOM检查是否有OOM事件，或systemctl show <服务名> | grep -E 'MemoryLimit|CPUQuota'查看是否配置了资源限制

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