Celery Worker的py-spy火焰图Polling相关问题咨询

环境信息 #

• Celery版本：5.2.7
• 消息中间件：RabbitMQ
• 结果后端：Redis
• 性能分析工具：py-spy 0.3.14
• Docker版本：24.0.7

Worker启动命令 #

celery -A app.client worker --pool=threads -l debug --concurrency=1

启动后包含1个主线程和1个工作线程，已通过py-spy生成火焰图。

疑问点 #

1. 为什么poll (kombu/utils/eventio.py:83)的CPU占比达到50.00%，和run (threading.py:953)占比相同？根据理解，未配置Celery限流时，Polling不应该阻塞，应该立即返回。
2. 为什么concurrent/futures/thread.py的第81行和第83行的耗时被分开统计？
3. 想确认poll (kombu/utils/eventio.py:83)和concurrent/futures/thread.py:81是否属于阻塞操作，是否需要关注，或是py-spy针对该Celery配置产生的统计假象。

已尝试用py-spy做性能分析、查看对应源码，但仍无法理解统计结果成因。

问题解答 #

关于poll (kombu/utils/eventio.py:83)占比高的原因 #

即使未配置限流，Celery Worker使用线程池模式时，主线程会通过kombu的eventio模块监听RabbitMQ消息队列。这里的poll并非空轮询，而是阻塞等待RabbitMQ的消息推送——当队列中没有待处理任务时，Worker会进入阻塞状态，此时poll会占用线程的执行时间，这是正常的空闲等待逻辑，并非性能瓶颈。

你看到的50%占比，是因为主线程（负责消息监听）和工作线程（负责任务执行）各占约一半的CPU时间：主线程大部分时间在poll等待消息，工作线程则在threading.py的run方法中运行任务或等待新任务，两者的时间占比自然接近。

关于concurrent/futures/thread.py行号拆分统计的原因 #

py-spy是基于采样的性能分析工具，会定期抓取Python线程的调用栈。concurrent/futures/thread.py的第81和83行属于线程执行循环的不同阶段：

• 第81行一般对应线程等待任务的逻辑（比如condition.wait()）
• 第83行对应线程获取任务后的执行逻辑

采样时线程可能在不同行被捕获，所以耗时会被分开统计，这是采样分析的正常现象，并非代码逻辑问题。

是否属于阻塞操作及是否需要关注 #

• poll (kombu/utils/eventio.py:83)：属于阻塞IO操作，但这是Worker空闲时的正常等待行为，无需关注——只有当队列中有大量任务但poll仍占比极高时，才需要排查RabbitMQ的消息推送延迟问题。
• concurrent/futures/thread.py:81：通常是线程等待任务的阻塞操作，同样是空闲状态的表现，除非任务队列积压但线程仍在此处等待，才需要排查任务分配逻辑。

这两个都不是py-spy的统计假象，而是Celery线程池模式下的正常运行状态。

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