Gunicorn 配置文件在一个 FastAPI 项目里,它的作用是把“怎么运行服务端进程”的一堆参数集中管理起来,用来以生产方式启动你的 ASGI 应用(FastAPI)并管理多进程/多 worker、超时、日志、预加载等。相比在命令行拼长串参数,用配置文件更可读、可复用、也更容易放进 Docker 或运维脚本里。
你给的启动方式:
gunicorn -c gunicorn_config.py app.main:app
含义是:
• -c gunicorn_config.py:加载这份配置文件。
• app.main:app:定位到你的 FastAPI 应用对象——模块 app/main.py 中名为 app 的变量。
它在 FastAPI 项目中的角色
• 进程管理:Gunicorn 采用 pre-fork 模型,主进程负责拉起/监控多个 worker,崩了会自动拉起,适合生产环境。
• 并发模型:FastAPI 是 ASGI(异步)应用,通常用 uvicorn 作为 worker 类(uvicorn.workers.UvicornWorker)。这样每个 worker 里跑一个高性能的 Uvicorn 服务器。
• 性能/稳定性参数:集中配置 workers 数量、timeout、keepalive、max_requests(防内存泄漏轮转)、preload_app(预加载加快启动)等。
• 日志与可观测性:统一 accesslog、errorlog、loglevel、访问日志格式等。
• 与反向代理配合:如 Nginx/ALB 后面运行时,处理 X-Forwarded-* 等头的信任范围。
一个常用的 gunicorn_config.py 示例(可按需裁剪)
gunicorn_config.py
import multiprocessing
监听地址/端口
bind = "0.0.0.0:8000"
worker 数量:常见经验值 CPU*2+1;也可按压测结果调优
workers = multiprocessing.cpu_count() * 2 + 1
使用 Uvicorn 作为 ASGI worker(FastAPI 推荐)
worker_class = "uvicorn.workers.UvicornWorker"
#(可选)如果没装 httptools/uvloop,可用 h11 版本:
# worker_class = "uvicorn.workers.UvicornH11Worker"
超时与连接保持
timeout = 60 # 请求处理超时(秒)
graceful_timeout = 30 # 优雅退出等待(秒)
keepalive = 5 # HTTP keep-alive(秒)
稳定性:处理一定请求数后重启 worker,缓解内存增长
max_requests = 1000
max_requests_jitter = 100
预加载应用(主进程先导入再 fork),加快启动与共享只读内存
注意:不要在模块顶层建立 DB 连接;在 FastAPI startup 里创建连接
preload_app = True
日志(“-” 表示输出到 stdout/stderr,便于容器收集)
accesslog = "-"
errorlog = "-"
loglevel = "info"
在反向代理后面时按需设置(尽量收敛,不要裸 “*”)
# forwarded_allow_ips = "127.0.0.1"
开发环境热重载(生产不要开)
# reload = True
什么时候用它、和 Uvicorn 有啥区别?
• 开发:通常直接 uvicorn app.main:app --reload,简单快速。
• 生产:用 gunicorn + uvicorn.workers.UvicornWorker 更健壮(主进程托管 worker、崩溃自愈、优雅重启、统一日志/超时策略等)。当然,uvicorn --workers N 也能多进程,但 Gunicorn 的进程管理/信号处理/生态更完善。
常见小贴士
• Linux/macOS 下用 Gunicorn;Windows 不支持(Windows 开发请用 uvicorn)。
• workers 不是越多越好,要结合 CPU 核数、IO 比例与压测结果调优。
• preload_app=True 时,避免在模块导入期创建不可 fork 的资源(如事件循环、线程池、DB 连接);把这些放到 FastAPI 的 startup 事件里。
• 放在 Docker 里时,CMD [“gunicorn”,“-c”,“gunicorn_config.py”,“app.main:app”] 很常见。
3260

被折叠的 条评论
为什么被折叠?



