合理workers值需匹配应用类型与资源：CPU密集型可用(2×核心数)+1为起点，IO密集型则需降低以防争抢连接池和OOM；实际应结合压测与下游依赖（如DB连接池）综合调优。
工作进程数不是越多越好，盲目设高反而拖慢响应、耗尽内存；关键在匹配应用类型与机器资源。
怎么算出合理的 workers 值
公式 (2 * CPU核心数) + 1 是起点，不是铁律。它适用于 CPU 密集型任务（如图像处理、数值计算），因为每个 worker 进程能真正并行跑满一个核。
- 查真实核心数用
os.cpu_count()或命令nproc，别信虚拟机/容器里显示的“逻辑处理器”数 - 双核机器设
--workers 5，四核设--workers 9，八核设--workers 17 - 但如果你的应用大量调数据库、发 HTTP 请求（I/O 密集型），worker 数设太高只会让进程争抢连接池和文件描述符，反而卡住
- 内存紧张时，每个 worker 要吃 50–100MB+，16GB 内存的机器设 17 个 worker 很可能 OOM
--workers 和 --threads 能不能一起用
可以，但收益有上限，且容易误配。同步模式（sync）下，--threads 才生效，每个 worker 会 fork 出多个线程共享内存。
- 启用线程必须加
--worker-class gthread，否则--threads被忽略 - 最大并发请求数是
workers * threads，但总并发能力仍受(2 * CPU) + 1约束——比如四核机器，--workers 3 --threads 3（共 9 并发）比--workers 9 --threads 1更稳，内存占用更低 - Flask/Django 默认不线程安全，多线程下要确认全局状态（如缓存、单例）没被意外修改
- 线程对 GIL 敏感，纯 Python 计算不会提速，只对 I/O 等待阶段有效
为什么开了 8 个 worker，压测 QPS 反而下降
常见原因不是配置错，而是没关掉开发模式或初始化冲突。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 代码里还留着
if __name__ == '__main__': app.run()？gunicorn 会跳过它，但某些框架（如 Flask）在 debug=True 时会强制启用重载器，导致每个 worker 都试图监听端口或重复初始化 DB 连接 - 数据库连接池没扩容：默认
pool_size=5，8 个 worker 同时抢 5 个连接，大量请求卡在“等待连接”状态 - 没加
--preload，导致每个 worker 都独立 import 模块、加载模型、解析配置，启动慢、内存重复占用高 - 日志级别太低（如
--log-level debug），磁盘写满或 IO 阻塞主线程
用 gevent 或 uvicorn worker 时 workers 还重要吗
仍然重要，但作用变了：它控制的是“协程调度器”的数量，不是请求处理单元。
-
gevent模式下，一个 worker 能并发几千请求，但所有协程跑在一个 OS 线程里，无法利用多核——所以workers仍建议设为(2 * CPU) + 1，让多个 worker 分摊到不同核心 -
uvicorn.workers.UvicornWorker（用于 FastAPI/Starlette）同理，--workers 4是合理起点，别设成 16 - 必须提前打 monkey patch：
from gevent import monkey; monkey.patch_all()，否则标准库（如socket、ssl）仍是阻塞的 -
worker_connections要配合调大（如 1000），否则协程还没跑起来就被连接数限制拦住
最常被忽略的一点：worker 数只是并发能力的“分母”，真正卡性能的往往是数据库连接池、Redis 连接数、HTTP 客户端超时、甚至 DNS 解析缓存。调 workers 前，先确认这些下游依赖是否撑得住同等并发量。
