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