Gunicorn 20.1.0配置workers后进程超限未回收问题咨询

针对你的两个疑问： #

1. Gunicorn是否会创建超出指定数量的20个worker？
   默认情况下不会。正常流程里，master进程会严格维持--workers指定的数量。但在worker重启的过渡阶段（比如旧worker处理完最后一个请求退出、新worker启动），会短暂出现worker数略高于设定值的情况，但不会持续增长到60+。如果出现持续增长，说明旧worker没有被正常终止，master进程不断启动新worker补充，最终导致进程堆积。

2. Gunicorn是否未终止已处理250个请求的worker？
   大概率是这样。旧worker未被正常回收，是进程数暴增的核心原因。

可能的原因： #

• worker进程卡住无法退出：应用代码处理请求时可能存在死锁、阻塞（比如等待永不返回的IO操作、数据库连接挂起），导致worker收到master的退出信号后无法正常终止。
• 信号处理异常：master进程发送的SIGTERM/SIGQUIT信号被应用代码拦截或忽略，worker无法响应退出指令。
• Gunicorn版本bug：你使用的20.1.0是2021年的旧版本，存在worker重启机制的已知问题，比如某些场景下master无法正确检测worker状态，导致重复创建新worker。
• 资源泄漏导致worker僵死：应用存在内存、文件句柄泄漏，随着请求处理次数增加，worker资源耗尽陷入僵死，无法正常退出。

解决建议： #

• 排查应用代码的阻塞/死锁问题：
  • 给worker添加超时配置：加上--timeout 30（根据业务调整时长），强制终止处理超时的worker。
  • 检查应用中的异步操作、第三方服务调用（数据库、API等），确保所有IO操作都设置超时限制。
• 升级Gunicorn版本：
  • 升级到最新稳定版（如21.x系列），后续版本修复了不少worker管理相关的bug，再观察问题是否复现。
• 调整worker重启参数：
  • 暂时降低--max-requests值（比如设为100），缩小--max-requests-jitter范围，减少同时重启的worker数量，降低过渡阶段的进程压力。
• 添加worker监控与日志：
  • 开启Gunicorn详细日志：加上--log-level debug，查看master和worker的启动、退出日志，确认是否有worker退出失败的提示。
  • 在容器内用ps aux或top定期查看进程状态，标记僵死的worker PID，结合应用日志分析该进程的最后请求记录。
• 限制容器进程数：
  • Docker运行时添加--pids-limit 60参数，避免进程无限制增长导致容器崩溃，作为临时应急措施。

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