FastApi搭配Gunicorn/Uvicorn服务无响应问题求助

环境配置 #

• 服务架构：FastAPI + Gunicorn/Uvicorn
• Gunicorn 配置：

TIMEOUT 0
GRACEFUL_TIMEOUT 120
KEEP_ALIVE 5
WORKERS 10

• Uvicorn 配置：默认配置
• Docker 启动命令：

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

• 部署方式：所有服务打包在Docker容器中

问题现象 #

服务运行一段时间后（1天至1周不等，取决于负载）完全无响应，即使执行简单的curl http://0.0.0.0:8000也会永久挂起。Docker容器仍在运行，日志中无应用错误或连接问题，但请求未到达任何工作进程，疑似在服务引擎与应用之间丢失。

负载复现结果 #

通过自定义Locust负载配置成功重现问题：

• 负载场景：
  1. 前15分钟逐步增加至50个用户，其中30个用户以1rps发送需GPU的请求，20个用户以10rps发送无需GPU的请求
  2. 持续运行4小时
• 现象：约30分钟后API停止响应，日志仍无错误或警告

排查发现 #

进入容器执行ps命令，结果显示Gunicorn服务已静默停止：

PID TTY          TIME CMD
    120 pts/0    00:00:00 bash
    134 pts/0    00:00:00 ps

同时应用目录下存在名为core的二进制文件，确认服务发生崩溃。

解决思路建议 #

1. 分析core dump文件：
   • 用gdb加载core文件和Python解释器，执行bt full查看崩溃堆栈，定位崩溃代码位置
   • 重点排查GPU相关请求处理逻辑，因为负载场景中GPU请求是核心压力源
2. 调整Gunicorn配置：
   • 取消TIMEOUT 0设置，改为合理值（如300），避免工作进程无限制挂起占用资源
   • 检查WORKERS数量是否超过容器资源上限（CPU/内存），建议调整为2*CPU核心数+1的标准值
3. 排查潜在死锁/内存泄漏：
   • 在GPU请求处理代码中添加超时控制，避免GPU资源被长期占用导致阻塞
   • 用memory-profiler或tracemalloc监控Python进程内存变化，定位内存泄漏点
4. 优化Docker与服务启动方式：
   • 确保Gunicorn作为容器PID=1进程运行，避免容器内进程管理异常
   • 调整启动命令为Gunicorn托管Uvicorn：

     CMD ["gunicorn", "app.main:app", "--workers", "10", "--timeout", "300", "--graceful-timeout", "120", "--keep-alive", "5", "--worker-class", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:8000"]
     

   • 给容器配置资源限制（CPU、内存），避免资源耗尽导致进程崩溃
5. 升级依赖版本：
   • 升级FastAPI、Uvicorn、Gunicorn到最新稳定版，修复已知的死锁或崩溃Bug

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