Uvicorn内存占用过高怎么办-Python教程-PHP中文网

uvicorn生产环境禁用--reload可显著降低cpu和内存占用，因该参数会持续监听文件、反复fork子进程并重复加载模块；实测删除后常驻内存从1.2gb降至200mb左右。

uvicorn内存占用过高怎么办

Uvicorn启动时带`--reload`导致CPU和内存双高

这是FastAPI项目在Docker中部署后Uvicorn内存飙升最常见的原因。开发阶段用--reload方便热重载，但生产环境主进程会持续监听文件变化、启动子进程、反复fork+exec，不仅吃CPU，还会因残留进程和重复加载模块造成内存堆积。实测显示，删掉--reload后，常驻内存能从1.2GB直接回落到200MB左右。

检查你的docker-compose.yml或启动命令，确认没有类似这样的配置：

command: uvicorn main:app --host 0.0.0.0:8000 --port 8000 --reload

改成生产模式写法：

command: uvicorn main:app --host 0.0.0.0:8000 --workers 4 --loop uvloop --http httptools

--reload只应在本地开发使用，CI/CD流水线或Docker镜像构建阶段也必须禁用
若用gunicorn做进程管理器（比如gunicorn -k uvicorn.workers.UvicornWorker），--reload更不能出现在任何层级
某些IDE插件或脚本会自动注入--reload，建议在容器内执行ps aux | grep uvicorn确认实际运行参数

worker数量设置不合理引发内存泄漏式增长

Uvicorn默认只启1个worker，看似省内存，但高并发下单worker事件循环容易卡住，请求排队、连接堆积、超时重试，最终表现为内存缓慢上涨且不释放。反过来说，worker设太多（比如8核机器配16个worker）也会因上下文切换和共享资源争抢，导致每个worker额外多占80–120MB内存。

推荐配置原则：

Uvicorn 0.52.1

Uvicorn 0.52.1 是 Python ASGI Web 服务器，提供异步应用服务及 WebSocket 支持，常用于 FastAPI、Starlette 等应用的开发和部署。本下载为官方 PyPI 通用 wheel 包，可使用 pip 安装，并由包管理器处理所需依赖。

下载

worker数 = CPU逻辑核心数 + 1（例如4核就设5个）
内存紧张时可降为CPU核心数，但别低于2（否则无法利用多核）
配合--limit-concurrency 1000防止单worker堆积过多连接
若用Redis或数据库长连接，确保每个worker独享连接池，避免跨worker复用导致句柄泄漏

Pydantic模型或大型依赖被反复导入

FastAPI重度依赖Pydantic，而Pydantic v2的BaseModel在首次导入时会动态生成大量代码对象并缓存，如果项目结构把模型分散在多个模块、又在路由中频繁from xxx import *，会导致同一模型被多次解析，sys.modules里出现冗余副本，GC难以回收。

典型症状：Uvicorn进程RSS持续缓慢上涨，重启后回落，几小时后又回到高位。

统一在models/目录集中定义所有Pydantic模型，全局只import一次
避免在router文件里直接from pydantic import BaseModel，改用from models import UserSchema
启用pydantic.v1兼容层（如必须）会加重开销，v2已优化不少，优先升级
用tracemalloc快速定位大对象来源：
```
python -X tracemalloc=10 -m uvicorn main:app
```
，然后访问/docs后调用tracemalloc.take_snapshot()分析

Docker容器未限制内存上限，OOM Killer误杀或缓存失控

没设mem_limit的容器，Linux内核会把空闲内存全给Uvicorn做page cache，表面看RSS很高，其实是缓存；但一旦其他进程申请内存，Uvicorn又来不及释放，可能触发OOM Killer直接干掉worker进程，日志里只留Killed process。

务必在docker-compose.yml中显式约束：

deploy:
  resources:
    limits:
      memory: 1.5G

设限值要比预估峰值高20%，比如压测发现稳定在1.1G，就设1.5G
配合--max-requests 1000让worker定期重启，强制释放长期持有的引用
禁用swap（mem_reservation不推荐），避免交换延迟放大响应时间

Uvicorn内存问题很少是“某一行代码写错”，更多是部署姿势、参数组合、环境隔离这三块没对齐。最容易被忽略的是：你以为删掉了--reload，结果Dockerfile里CMD又写死了一次；或者worker数调对了，但Redis客户端没配max_connections，连接池随worker数翻倍膨胀——这些细节叠加起来，才让内存看起来“莫名其妙”地高。