问题是一个非常严重的内存泄漏，直到服务器崩溃为止（或者您可以通过杀死芹菜工人服务来恢复，该服务释放了所有使用的RAM）
在此问题上似乎有很多报道的错误，但是在芹菜API文档中，很少关注此警告，这里
警告：后端使用资源存储和传输结果。为了确保发布资源，您必须最终 call get（）或上的每个在调用任务后返回的每个 aryncresult实例。
，可以合理地假设泄漏与此警告有关。
但是，概念问题是，基于我对芹菜的理解，异步实例是在用户会话中跨多个django视图创建的：在一个视图中启动/产生新任务时，有些是在一个视图中创建的，稍后您可能会创建一些任务手动（使用保存在用户会话中的task_id）在另一个视图中检查这些任务的进度（状态）。
因此，Asynresult对象最终将在现实世界中的多个视图中脱离范围，并且您不想在任何这些视图中调用get（），因为您不想放慢速度django（或apache2）守护程序。
在调用get（）方法之前，永远不要让异步对象脱离范围？
celery_result_backend ='django-db'#backend是mysql db
broker_url ='pyamqp：//localhost'#rabbitmq
我们还面临生产中芹菜的多个问题，还解决了记忆泄漏问题。我不确定我们的问题范围是否相同，但是如果您不介意，您可以尝试我们的解决方案。
您看到我们有多个由主管管理的工人运行的任务（所有工人都处于同一队列）。现在，我们看到的是，当有很多任务被排队时，经纪人（在我们的情况下，RabbitMQ）正在发送芹菜工人可以处理并将其余的任务保留在记忆中的任务数量。这导致了我们的记忆力溢出，经纪人开始在我们的硬盘驱动器中互动。从阅读文档中，我们发现，如果我们允许经纪人不等待工人的成绩，则可以解决此问题。因此，在我们的任务中，我们使用了该选项，
@task(time_limit=10, ignore_result=True)
def ggwp():
# do sth
在这里，时间限制将在一定时间之后关闭任务，而imagore_result选项将允许经纪人一旦释放工人就可以在芹菜工人中发送任务。