Gunicorn Procfile配置--max-requests重启是否会中断运行任务

核心结论 #

针对你关心的两个问题，直接给基于Gunicorn实际运行逻辑的明确答案：

1. 不会直接暴力杀死正在运行的请求/任务
2. 不会等worker完全空闲才重启，而是等当前在途请求处理完成后立刻退出

具体运行逻辑 #

• 每个Gunicorn worker进程会独立计数自己处理完成的请求数量，当计数达到--max-requests设置的阈值（如果配置了--max-requests-jitter会叠加随机偏移值，避免所有worker同时重启），worker会立刻进入优雅关停流程，不会再接收主进程转发的新请求，新请求会被自动分配给其他正常运行的worker。
• 进入关停流程的worker会等待当前正在处理的所有请求执行完成，只要所有在途请求处理完毕，worker就会立刻退出，由主进程拉起新的worker补位，不会额外等待"完全空闲"的状态。
• 等待在途请求的最长时间由--graceful-timeout参数控制，默认值是30秒。如果在这个时间窗口内还有请求没处理完，worker才会被强制终止，对应请求会返回502错误。

Django场景配置建议 #

• 不要只单独配置--max-requests，一定要搭配--max-requests-jitter使用，Procfile里的启动命令可参考：

  web: gunicorn your_project.wsgi --max-requests 1200 --max-requests-jitter 200 --workers=4 --graceful-timeout 60
  

  上面的配置会让每个worker处理1000-1400之间随机数量的请求后自动重启，避免所有worker同时重启造成服务抖动，同时把优雅等待时间设为60秒，覆盖大部分Django常规请求的耗时场景。
• 如果你的服务有大文件导出、批量计算这类长耗时接口，记得把--graceful-timeout调整到比你最长的正常接口耗时多10-20秒，避免正常请求被中途切断。
• 这个方案是生产环境临时解决worker内存泄漏的标准实践，参数配置合理的情况下，终端用户完全感知不到worker的重启过程，可以放心上线。

内容的提问来源于stack exchange，提问作者Vipul Vishnu av