为何Gunicorn启动的Worker进程数是请求值的3倍？

核心原因：Gunicorn递归启动进程 #

你看到的嵌套进程结构，是因为Gunicorn的worker进程重复启动了Gunicorn本身，形成递归启动，最终进程数远超预期的3个。主要触发场景有两种：

1. Shell形式的启动命令导致递归 #

如果你的command使用字符串形式（如command: gunicorn -w 3 ...），Docker会通过/bin/sh -c执行这条命令。Gunicorn以fork模式创建worker时，worker进程会继承父进程的执行环境，重新运行/bin/sh -c "gunicorn ..."，每个worker又会启动新的Gunicorn主进程，该主进程再创建3个worker，以此类推形成嵌套进程树。

2. Docker配置重复启动Gunicorn #

如果你的Dockerfile中已经通过ENTRYPOINT或CMD配置了Gunicorn启动命令，同时docker-compose的command又重复指定完整的Gunicorn命令，也会导致嵌套启动——Dockerfile的命令启动Gunicorn主进程，而docker-compose的命令让这个主进程的worker再次执行启动命令。

解决方法 #

方法一：使用Exec形式的命令 #

将docker-compose中的command改为数组形式（Exec格式），避免Shell解析，这样Gunicorn的worker不会重新执行启动命令：

command: ["gunicorn", "-w", "3", "-b", "0.0.0.0:9000", "myapp.wsgi:server"]

方法二：清理重复的启动配置 #

检查你的Dockerfile，确保ENTRYPOINT和CMD没有与docker-compose的command重复配置Gunicorn启动逻辑。例如：

• 如果Dockerfile已设置CMD ["gunicorn", "-b", "0.0.0.0:9000", "myapp.wsgi:server"]，docker-compose的command只需覆盖worker数量：

  command: ["gunicorn", "-w", "3", "-b", "0.0.0.0:9000", "myapp.wsgi:server"]
  # 或更简洁（基于Dockerfile的基础命令）：
  # command: ["-w", "3"]
  

验证解决效果 #

修改配置后重启容器，用ps -auxf检查进程树，正常结构应为：

/usr/bin/containerd-shim-runc-v2 ...
 \_ /usr/local/bin/python /usr/local/bin/gunicorn -w 3 -b 0.0.0.0:9000 myapp.wsgi:server
     \_ /usr/local/bin/python /usr/local/bin/gunicorn -w 3 -b 0.0.0.0:9000 myapp.wsgi:server
     \_ /usr/local/bin/python /usr/local/bin/gunicorn -w 3 -b 0.0.0.0:9000 myapp.wsgi:server
     \_ /usr/local/bin/python /usr/local/bin/gunicorn -w 3 -b 0.0.0.0:9000 myapp.wsgi:server

仅包含1个主进程+3个worker进程，共4个Gunicorn相关进程。

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