django - 在有消息等待的情况下，在Amazon Elastic Beanstalk上使用SQS的Celery经常长时间停顿

Question

我目前正在将现有的基于Django的单个服务器的Web项目移植到Amazon Elastic Beanstalk。到目前为止，我已经成功地将项目设置为使用RDS，Elastic Search，简单电子邮件服务和S3，而没有太多麻烦。我正在使用Code Deploy为Django项目构建Docker容器并将其部署到Elastic Beanstalk环境。所有这些都能很好地工作，但是我在尝试使Elastic Beanstalk worker 环境与该设置良好配合时遇到问题。

我正在将相同的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容器的 celery 日志，我可以看到捡起8-12条消息之间的任何地方的组，然后在一两秒钟内进行处理，但是随后该 worker 一次空闲了几分钟。通常大约需要4分钟。

我没有想到可以想到的任何错误。

我还尝试了扩大工作环境，使其运行多个工作节点，但这只是将问题分散到了多个节点上。即，不是由一个工作人员接收8-12条消息，而是由两名工作人员在4-6条消息之间进行提取，处理它们，然后进入空闲状态。

在这一点上，我不知道我应该再看什么，并且我正在考虑完全放弃工作环境。在与Web服务器相同的环境中运行Celery worker进程也许更有意义？我不想这样做，因为我认为为Web服务器和工作人员独立设置扩展规则会容易得多，但是看起来我别无选择。

我在此设置中是否缺少某些内容，或者某些原因导致Celery worker 环境以这种方式运行？

Answer 1

鉴于更改 celery worker 或节点的数量不会改变延迟，这使我相信问题出在给定的 celery worker 如何尝试将任务从SQS队列中拉出。

超时4分钟后，似乎非常接近default retry delay present in Celery's Task.default_retry_delay(即3分钟)。它也可能与Task.rate_limit和the config parameter有关，它将限制 celery worker 在给定时间单位内接受的任务总数。

第一步，我将进入您的celery配置文件并手动更改这两个值-将它们设置得更高，并查看它如何影响超时或更改应用程序吞吐量。