切换到Gunicorn后Django AI音频转录应用内存溢出问题排查

一、内存优化：降低单Worker内存负载 #

• 合理配置Gunicorn Worker参数
  不要盲目增加Worker数量，根据容器CPU核心数调整，同时避免内存泄漏：

  # 建议配置：CPU核心数*2+1，配合请求重启机制
  gunicorn --workers=3 --worker-class=sync --max-requests=100 --max-requests-jitter=50 --timeout=120 your_project.wsgi:application
  

  说明：--max-requests让Worker处理指定请求数后自动重启，防止内存持续累积；--timeout仅作为基础适配，需结合其他优化生效。
• 优化音频处理流程
  • 避免全量加载音频到内存：使用pydub或librosa的分块读取功能，将长音频切割为10分钟以内的片段，分段转录后合并结果
  • 即时释放资源：转录完成后手动删除音频对象、模型实例，必要时调用gc.collect()清理内存
• 轻量化AI模型
  • 切换至更小的转录模型（如Whisper的base/small版本，替代large模型）
  • 启用模型量化：用bitsandbytes实现4/8位量化，可将模型内存占用降低50%-75%

二、架构重构：异步解耦长耗时任务 #

• 引入任务队列（Celery+Redis）
  将音频转录逻辑从Gunicorn Worker中剥离，交给后台异步任务处理：
  1. 在requirements.txt添加依赖：

     celery==5.3.4
     redis==5.0.1
     

  2. 编写Celery异步任务，将音频存储（本地/对象存储）、转录、结果存储逻辑移至任务函数；Django视图仅负责接收文件、提交任务并返回任务ID，由用户前端轮询结果
  3. 为Celery Worker单独配置容器，分配独立内存资源，避免与Gunicorn抢占内存
• Docker资源精细化分配
  在docker-compose.yml中为不同服务设置内存配额：

  services:
    web:
      build: .
      command: gunicorn --workers=3 --timeout=60 your_project.wsgi:application
      deploy:
        resources:
          limits:
            memory: 2G
          reservations:
            memory: 1G
    celery_worker:
      build: .
      command: celery -A your_project worker --loglevel=info
      deploy:
        resources:
          limits:
            memory: 4G
          reservations:
            memory: 2G
      depends_on:
        - redis
    redis:
      image: redis:alpine
  

三、排查与验证 #

• 开启Gunicorn调试日志
  添加--log-level=debug参数，定位Worker被SIGKILL前的内存使用细节
• 实时监控内存峰值
  用docker stats跟踪长音频处理时的容器内存变化，确认是模型加载还是音频处理导致的溢出
• 梯度测试验证
  逐步增加音频长度，测试优化后的内存阈值，验证方案有效性

临时应急方案（不推荐长期使用） #

若暂无法重构架构，可临时调整：

• 延长Gunicorn超时时间：--timeout=300
• 提高Docker容器内存配额：在运行命令或docker-compose.yml中增大--memory参数

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