我目前正在将现有的基于Django的单服务器Web项目移植到Amazon Elastic Beanstalk。到目前为止，我已经成功设置了项目以使用RDS，Elastic Search，简单电子邮件服务和S3，而没有太多麻烦。我正在使用Code Deploy为Django项目构建Docker容器并将其部署到Elastic Beanstalk环境。所有这些都能很好地工作，但是我在尝试使Elastic Beanstalk工作者环境与该设置良好配合时遇到问题。
我正在将相同的Docker容器部署到我的工作人员环境中，但是起点不同，可以运行celery -A project worker -l INFO而不是gunicorn config.wsgi --bind 0.0.0.0:5000 --chdir=/app --workers 3。这似乎可行；工作人员可以使用消息并对其进行很好的处理，但是即使队列中有待处理的消息积压，它也似乎经常一次停止工作几分钟。
在测试期间，我正在尝试运行我的发票生成例程，该例程通过在group中使用Celery chain将每个帐户的发票的消息排队，以便它将处理发票，然后给我发送“完成”通知。一开始，队列中总共有大约250条消息。跟踪Docker容器的芹菜日志，我可以看到在8到12条消息之间的任何地方都被捡起，然后在一两秒钟内进行处理，但是工人一次空闲了几分钟。通常大约4分钟。
我认为可以看到的任何地方都看不到任何错误。
我还尝试了扩大工作环境，使其运行多个工作节点，但这只是将问题分散到了多个节点上。即，不是由一个工人接收8到12条消息，而是由两个工人在4到6条消息之间提取，处理它们，然后进入空闲状态。
在这一点上，我不知道应该再看什么，并且我正在考虑完全放弃工作环境。在与Web服务器相同的环境中运行Celery worker进程也许更有意义？我宁愿不这样做，因为我认为为Web服务器和工作人员独立设置缩放规则会容易得多，但是看来我别无选择。
此设置中是否缺少某些内容，或者某些原因导致Celery工作者环境以这种方式运行？
答案 0 :(得分：2)
鉴于更改芹菜工作者或节点的数量不会改变延迟，这使我相信问题出在给定的芹菜工作者如何尝试从SQS队列中拉出任务。
4分钟的超时时间似乎非常接近default retry delay present in Celery's Task.default_retry_delay，即3分钟。也可能与Task.rate_limit，the config parameter有关，这将限制芹菜工作者在给定的时间单位内要接受的任务总数。
首先，我将进入您的celery配置文件并手动更改这两个值-将它们设置得更高，并查看它如何影响超时或更改应用程序吞吐量。