sync worker 在 i/o 密集场景下易卡死，因其同步阻塞特性使整个进程在数据库查询、http 调用等操作时停滞，导致 503 增多、worker timeout、请求堆积；根本原因非参数可解，需换 gevent/eventlet 或异步 worker。
sync worker 为什么在 I/O 密集场景下容易卡死
sync worker 是 Gunicorn 默认模型，每个 worker 对应一个 OS 进程，用同步阻塞方式处理请求。一旦遇到数据库查询、HTTP 调用、文件读写等 I/O 操作，整个 worker 就停在那里，无法响应新请求。
常见错误现象：503 Service Unavailable 突然增多、gunicorn 日志里大量 Worker timeout (pid:xxx)、CPU 使用率低但请求堆积严重。
适用场景：纯 CPU 计算型服务（如图像缩放、数值计算），或已用异步客户端（如 aiohttp）但没配对 worker 类型。
- 不要在调用
requests.get()或psycopg2.connect()的 Web 接口里硬扛 sync worker -
--workers设太高会吃光内存，设太低又压不住并发——这不是调参能解决的根本问题 - Python 的 GIL 不影响 sync worker 的进程隔离性，但 I/O 阻塞本身不受 GIL 控制，所以卡是实打实的
gevent worker 要求代码“无阻塞”但不强制 async/await
gevent 通过 monkey patch 把标准库里的阻塞调用（如 socket、ssl、threading）替换成协程友好的版本。它不要求你改写成 async def，但要求所有 I/O 调用最终落到被 patch 过的底层上。
立即学习“Python免费学习笔记（深入）”；
容易踩的坑：gevent.monkey.patch_all() 必须在任何其他 import 之前执行；否则像 requests 可能仍走原生阻塞 socket；某些 C 扩展（如 ujson、numpy）不兼容 patch，但一般不影响 HTTP 处理。
- 启动命令必须加
--worker-class gevent --worker-connections 1000，后者定义每个 worker 最大协程数 -
gevent不支持 Windows，开发机是 Win？别试了，直接换 WSL 或 Linux 容器 - 如果用了
celery，注意gevent和celery的 event loop 冲突，需用celery -P gevent显式指定
eventlet worker 和 gevent 的关键区别在哪
两者都靠 monkey patch 实现协程，但 eventlet 更早支持 SSL/TLS 分块读写，在某些 HTTPS 后端代理（如 Nginx + keepalive）下更稳；gevent 在高并发短连接场景下调度开销略小，生态支持略广（比如 psycopg2 官方文档明确推荐 gevent）。
性能差异在大多数业务中感知不强，但兼容性问题很具体：
-
eventlet对threading.local支持较弱，如果你依赖线程局部变量存 request context（比如 Flask 的g），可能出错 -
eventletpatch 后的time.sleep()行为和原生不同，单元测试里写time.sleep(0.1)等待异步完成？大概率失败 - 不能混用：
gevent和eventlet的 patch 互斥，装了两个还都 patch，Gunicorn 启动直接报ImportError: cannot import name 'hubs'
怎么判断你的应用该选哪个 worker
别猜，看 I/O 调用链路是否可控。如果项目里大量使用 requests、redis-py、psycopg2 这类同步阻塞库，又没精力重构成异步，gevent 是最现实的选择。
真实使用场景参考：
- Django 项目 + PostgreSQL + requests 调第三方 API → 用
gevent，加--worker-class gevent --worker-connections 1000 --timeout 30 - Flask + SQLite（文件锁敏感）→ 别用 gevent/eventlet，SQLite 的 WAL 模式在协程下有竞争风险，老实用 sync +
--workers 2 - FastAPI + httpx.AsyncClient → 用
uvicorn，不是 Gunicorn 的活；非要用 Gunicorn，得配--worker-class uvicorn.workers.UvicornWorker，和 gevent/eventlet 无关
最常被忽略的一点：worker 类型选错，日志里不会报错，只会慢慢变慢、超时、OOM——得靠 gunicorn 的 --statsd-host 或进程级监控（如 ps aux --sort=-%cpu）才能发现 worker 是否真在干活。
