怎样在Linux生产机上调优Python WSGI服务器的工作进程并发参数？-Python教程-PHP中文网

--workers设为cpu核心数×2出问题，因其仅适用于纯cpu密集型场景；生产中python web服务多为i/o密集型，同步worker模型下过多进程会导致内存暴涨、上下文切换开销上升、数据库连接池被打穿，建议i/o密集型服务起始值设为cpu核心数+1并搭配gevent。

怎样在linux生产机上调优python wsgi服务器的工作进程并发参数？

为什么 `gunicorn` 的 `--workers` 设成 CPU 核数 × 2 就出问题？

这个经验值只适用于纯 CPU 密集型、无阻塞 I/O 的场景。生产中 Python WSGI 服务（尤其是 Django/Flask）常调用数据库、Redis、HTTP API，gunicorn 的 worker 是同步模型，每个 worker 进程同一时间只能处理一个请求。设太多 worker 会导致：内存暴涨（每个 worker 加载完整应用）、上下文切换开销上升、数据库连接池被打穿（如 psycopg2 默认每进程最多 20 连接，16 个 worker 就可能占满 320 连接）。

实操建议：

python-code-analyz

专业Python代码分析与优化，支持语法检查、安全扫描、性能评估、复杂度分析及重构后优化代码生成。

下载

先查当前机器真实负载：uptime 和 cat /proc/loadavg，若 15 分钟 load > CPU 核数 × 1.2，说明已有积压，盲目加 worker 会恶化
用 ps aux --sort=-%mem | head -10 看单个 worker 内存占用，乘以预估 worker 数，确认不超过可用内存的 70%
对 I/O 密集型服务，更稳妥的起始值是 CPU 核数 + 1（例如 4 核机器设 --workers=5），再配合 --worker-connections=1000（需搭配 --worker-class=gevent）提升吞吐

`uWSGI` 的 `processes` 和 `threads` 怎么配才不翻车？

uWSGI 支持多进程+多线程混合模型，但 Python 的 GIL 让多线程对 CPU 密集任务收益极低，反而增加锁竞争。线上真正有效的组合是：少量进程 + 每进程开适量线程（仅适用于明确做了 I/O 解耦的代码，比如用 asyncio.to_thread 或 concurrent.futures.ThreadPoolExecutor 包裹阻塞调用）。

实操建议：

禁用 enable-threads = true 除非你确认所有第三方库（含 DB 驱动）线程安全；否则优先用 --processes=4 --threads=2 而非 --processes=2 --threads=4
必须设置 --max-requests=1000 和 --max-requests-delta=100，防内存泄漏累积（尤其用了 lru_cache 或全局 dict 缓存时）
检查 uwsgi --show-config 输出，确认 harakiri（超时杀进程）和 reload-on-rss（内存超限重启）已启用，值建议设为 harakiri=30、reload-on-rss=300（MB）

如何验证并发参数调优是否真有效？

不能只看 QPS 上升——很多调优让平均延迟下降，但长尾 P99 延迟飙升，用户实际感知更差。关键要看三组指标是否同步改善：

应用层：用 ab -n 1000 -c 100 http://localhost:8000/health/ 测基线，再对比 gunicorn --statsd-host 或 uWSGI --stats 暴露的 metrics（重点关注 worker_busy、respawn_count）
系统层：用 pidstat -u -p $(pgrep -f "gunicorn|uwsgi") 1 观察各 worker CPU 使用率是否均衡（>80% 持续即瓶颈，
依赖层：用 netstat -anp | grep :5432 | wc -l（PostgreSQL）或 redis-cli info clients | grep connected_clients 确认连接数未触顶

别忽略 WSGI 服务器和反向代理之间的队列错配

Nginx 默认 proxy_buffering on 且缓冲区小，当后端 worker 处理慢，Nginx 会把响应体缓存在内存里，导致 gunicorn 的 --timeout 到期前，Nginx 已经断连并返回 502。这时调大 --workers 反而加剧 Nginx 缓冲区耗尽。

实操建议：

Nginx 配置中必须加：proxy_read_timeout 60、proxy_send_timeout 60、proxy_buffer_size 128k、proxy_buffers 4 256k
在 WSGI 侧，gunicorn 要设 --timeout=45（比 Nginx 的 proxy_read_timeout 小 15 秒），留出网络传输余量
用 curl -v http://localhost/ 检查响应头是否有 X-Upstream-Status 或 X-Response-Time，确认超时控制链路完整

真实生产环境里，worker 数量不是性能瓶颈的唯一开关。最常被跳过的动作是：没关掉开发模式残留的 DEBUG=True（Django）或 app.debug=True（Flask），它会让每个请求重编译模板、检查文件变更，直接吃掉 3× 以上 CPU。调参前先确认这点，比反复改 --workers 有用得多。