伙计们，
我有一个小问题，也许有人可以帮我弄清楚这里到底发生了什么：
我有数千个相同的任务应该在几毫秒内执行，并且在我重新启动工作人员后它们实际上会在几毫秒内执行，但是在记录了一堆这些任务之后，我从 celery 中得到一个大斑点，说它们已经完成（http ://d.pr/n/66h）在更长的时间范围内一起完成......之后，每个任务都需要大约 5-13 秒才能执行。这让我计算出 celery 可以在大约一周的执行时间内完成所有任务。（啊啊啊啊啊）
可以说，在工人重新启动后，大约 30-60 个任务会以正常速度执行。之后我每隔几秒就会得到一个结果——就像上面提到的那样，有点像 4-13 秒。当然，在某些情况下，要做的事情比其他情况多一点，但这并不能证明从 0.08s 到 13s 的差异是合理的！
我目前使用 redis 作为代理（很快将切换到 RabbitMQ），结果后端和任务本身将一些数据保存到 Solr 实例，但所有这些连接仍应在几毫秒内完成！
我希望能够弄清楚究竟是什么延迟了所有这些任务。有人吗？
快乐的安迪
我们在这里遇到了同样的问题。我们通过在 django-settings 中使用 celery-settings 解决了这个问题。在降低并发性（到 2）并将其重置为原始状态（10）后，一切正常。也许试一试。
经过长时间的偶尔修复和破坏它的斗争后，我发现问题出在工人本身（和配置 - 我的错）。配置说要将结果写入后端，它做得很好，结果有点像 50k，结果坐在“垃圾箱”里..及时工人变得反应迟钝..经过几个小时的摆弄，我得到了我在本地调试工作人员的地方，令我惊讶的是，在 redis 响应方法期间卡住了。
这有点“只是”在服务器上花费了大约 10 秒，但对于我的拨号连接来说有点像永远。因此，我在 redis 响应方法中添加了一个打印，并看到 redis 中可用的所有 50k 结果键都被流式传输到我的机器......对于每个执行的任务。
所以这就是一切变得毫无反应的真正原因。添加 celery 的设置以停止扭曲结果并清除 redis 后端立即解决了问题。
我仍然想知道为什么 redis 喜欢请求密钥，尽管它不应该使用 em。我没有以任何方式评估结果，否则一开始就不会有 50k。:P
无论如何-对于将代码放在那里这么长时间并感谢所有鱼的那个人