python web应用cpu打满主因是gunicorn配置与负载错配：i/o密集型服务盲目堆高worker数（如4核设16+）引发oom震荡，sync worker遇i/o阻塞导致低cpu高延迟，gevent未正确patch则协程失效，需合理选型并启用preload和max_requests防内存泄漏。
Python Web应用在高负载下CPU打满，通常不是“服务器不够强”，而是gunicorn配置、worker类型或应用自身逻辑与负载特性错配导致的——尤其常见于I/O密集型服务上堆了过多同步worker。
为什么gunicorn --workers设多反而更卡
盲目套用“2×CPU核心数+1”公式，在Flask/Django这类I/O密集型服务上极易引发调度抖动和内存争抢：
- 4核机器用
gevent模式时，--workers 8~12已足够；设到16+后，每个worker分到的内存变少，频繁触发GC，ps aux --sort=-%cpu里能看到RSS列差异极大 - 部分worker被OOM killer干掉又重启，形成“CPU持续100% + 进程PID频繁变化”的震荡现象
-
syncworker在数据库查询或HTTP调用卡住时，整个worker阻塞，但CPU可能不高、延迟却飙升——你看到的是“低CPU高延迟”，但错误地以为要加worker
sync / gevent / uvicorn.workers.UvicornWorker怎么选
选错worker-class是压不出QPS还CPU爆表的主因：
-
sync：适合纯计算型短请求（如返回静态JSON），但遇I/O就堵死；不推荐用于带DB或外部API调用的服务 -
gevent：单worker可并发数百连接，但必须在应用入口第一行加from gevent import monkey; monkey.patch_all()；漏掉这句，requests、psycopg2仍走系统阻塞调用，协程不生效，CPU反而更烫 -
uvicorn.workers.UvicornWorker：ASGI服务的正确姿势，但--workers必须设为1（由Gunicorn管进程数）；若你在Uvicorn命令行里再写--workers 4，会冲突报错或静默降级
启动后还是跑在开发服务器上？检查这三个地方
现象是gunicorn app:app启动后，ps aux里看不到gunicorn进程，只有python进程且CPU 100%——大概率是Flask调试模式没关干净：
- 全局搜索并删掉所有
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
这两个参数不写进启动命令，往往导致worker内存缓慢泄漏、GC压力增大，最终CPU在长周期运行后逐步爬升至100%：
-
preload=True让Gunicorn先加载应用再fork worker，避免每个worker重复导入模块、初始化连接池，减少内存碎片 -
max_requests=1000（或max_requests_jitter=100）强制worker处理一定请求数后优雅重启，防止长连接、缓存累积、引用计数异常等引发的隐性资源泄漏
真正难排查的，是那些没报错、没日志、CPU缓慢爬升到100%才暴露的问题——它们往往藏在preload没开、max_requests没设、或者monkey.patch_all()漏调用的缝隙里。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
