Django集成ML项目遇Worker停止警告：内存泄漏/超时问题求解

警告含义 #

先看触发的警告内容：

UserWarning: A worker stopped while some jobs were given to the executor. This can be caused by a too short worker timeout or by a memory leak.

这个警告说明：负责执行任务的工作进程（worker）在执行器分配的任务完成前就意外终止了，导致部分任务没有被正常处理。触发原因主要分为两类：

1. Worker的超时阈值设置过短，任务还未执行完毕就被强制终止
2. 程序存在内存泄漏问题，worker进程占用的内存超过系统限制，被操作系统强制杀死

针对性解决方法 #

一、处理超时设置过短的情况 #

• 调整执行器/服务器的超时参数：
  如果使用Gunicorn作为WSGI服务器，启动时通过--timeout参数延长超时时间，比如：

  gunicorn myproject.wsgi:application --timeout 120
  

  （将超时设为120秒，可根据你的ML任务实际耗时调整）
  如果用Celery处理异步任务，在Django的settings.py中修改任务超时配置：

  CELERY_TASK_TIME_LIMIT = 300  # 设置为300秒，即5分钟
  

• 拆分长任务：
  把单次耗时久的ML任务（比如全量数据集加载+模型推理+结果对比）拆分为多个小任务分步执行，比如先加载数据集片段、再做预处理、最后执行对比计算，避免单个任务因耗时过长触发超时。

二、处理内存泄漏的情况 #

• 优化ML模型与数据的内存管理：
  避免在全局作用域加载大模型（多worker环境下每个worker会单独加载一份，会大幅占用内存），建议在视图函数内部按需加载模型，或者使用单例模式控制模型实例数量；对于超大数据集，改用分批读取的方式，不要一次性将全部数据加载到内存。
• 监控并限制worker内存：
  用top或ps aux命令实时查看worker进程的内存占用，定位内存增长的环节；同时可以给worker设置自动重启机制，比如Gunicorn的--max-requests参数，让worker处理指定数量的请求后自动重启，防止内存持续累积：

  gunicorn myproject.wsgi:application --max-requests 100
  

• 排查代码中的内存泄漏点：
  检查循环逻辑是否存在未释放的变量，比如Pandas DataFrame使用后是否及时清空，PyTorch/TensorFlow的张量是否调用.to('cpu')并清理缓存；避免使用全局变量存储大对象，防止内存无法被回收。

内容的提问来源于stack exchange，提问作者Priyanshu Sinha