Gunicorn CPU 100%主因是worker数量或类型与I/O密集型负载不匹配：4核机器gevent模式下8~12个worker更合理，超设致内存不足、频繁GC及OOM震荡。
CPU占用率100%不是因为Gunicorn没起多进程，而是worker数量、类型或初始化逻辑和你的应用负载不匹配——尤其常见于I/O密集型服务上盲目堆高worker数。
gunicorn --workers设多少才合理
别套用“2×CPU核心数+1”这种通用公式。对Flask/Django这类I/O密集型服务，worker太多反而引发内存争抢和调度抖动：
- 4核机器上，
gevent模式下8~12个worker通常已足够；设到16+后，每个worker分到的内存变少，频繁触发GC，ps aux --sort=-%cpu里能看到RSS列差异极大，说明部分worker被OOM killer干掉又重启，形成震荡 - CPU密集型任务（如图像处理、数值计算）才真正需要多进程；但CPython的GIL会让纯计算型代码在
syncworker里收益有限，此时应优先考虑用uvicorn.workers.UvicornWorker+ 多进程组合 - 启动时加
--log-level info，确认实际加载的worker数——有时配置写了4个，但因端口占用或权限问题，只起了1个，你却在top里看到它吃满CPU
sync / gevent / uvicorn.worker 三种worker-class怎么选
选错worker-class是CPU打满又压不出QPS的主因：
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
sync：每个worker一次只处理1个请求，适合短平快响应（如返回JSON配置），但数据库查询或HTTP调用一卡，整个worker就堵死；此时CPU可能不高，但延迟飙升 -
gevent：单worker可并发处理数百连接，但必须在应用最开头加from gevent import monkey; monkey.patch_all()，否则requests、psycopg2等库仍走系统阻塞调用，协程不生效，CPU反而更烫 -
uvicorn.workers.UvicornWorker：这是ASGI层的正确打开方式，但--workers必须设为1（由Gunicorn管进程数），若你在Uvicorn命令行里再写--workers 4，会冲突报错或静默降级
为什么删了app.run()还是跑在开发服务器上
现象是gunicorn app:app启动后，ps aux里看不到gunicorn进程，只有python进程，且CPU持续100%——大概率是Flask调试模式没关，或者app.run()没彻底清理：
立即学习“Python免费学习笔记（深入）”；
- 检查所有文件，删掉或注释掉所有
if __name__ == '__main__': app.run()，哪怕它藏在tests/目录里也得清掉 - 确认
FLASK_ENV和FLASK_DEBUG环境变量没设为development，否则Flask会自动启用重载和调试器，拖慢并吃光CPU -
gunicorn不读取.env或config.py，所有配置必须显式加载：app.config.from_object('config.ProdConfig')，否则DEBUG=True开着跑生产，等于裸奔
preload=True 和 max_requests=1000 这两个参数容易被忽略
它们不直接影响CPU，但间接决定worker是否健康存活：
-
preload=True让主进程在fork worker前先导入应用代码，避免每个worker重复导入、初始化DB连接池或加载大模型——否则4个worker各自load一遍PyTorch模型，内存翻4倍，swap开始狂打，CPU在page fault里打转 -
max_requests=1000强制worker处理1000个请求后退出重启，防止内存泄漏累积；不设的话，某个worker扛着长连接+缓存越跑越重，最终被OOM kill，Gunicorn拉起新worker又重复加载，形成“CPU高→OOM→重启→CPU高”循环
