worker_processes直接决定Nginx并行处理请求的执行单元数量，是并发能力的底层支撑；应设为CPU核心数或auto，避免过多导致上下文切换开销、过少造成CPU浪费，需配合worker_cpu_affinity、worker_rlimit_nofile和worker_connections协同调优。
worker_processes 直接决定 Nginx 能并行处理请求的“执行单元”数量，是并发能力的底层支撑点。它不提升单个请求的速度，但决定了服务器能否把多核 CPU 的算力真正用起来——设少了，再强的硬件也跑不满；设多了，反而因调度混乱拖慢整体响应。
核心逻辑：一个进程对应一个 CPU 核心的高效利用
每个 worker 进程是独立、单线程、事件驱动的，能同时管理成千上万个连接（靠 epoll/kqueue）。理想状态下，让每个 CPU 核心只运行一个 worker，就能避免跨核缓存失效、减少上下文切换，实现最轻量的资源调度。
- 8 核服务器配 worker_processes 8，8 个 worker 各守一核，负载均衡且无争抢
- 若设为 16，系统需频繁切换进程，CPU 时间片大量耗在调度上，实测 QPS 反而下降 5%～15%
- 若设为 1，哪怕 32 核机器，所有请求全挤在一个进程里，CPU 利用率可能不到 20%，并发瓶颈立刻暴露
推荐配置方式：优先用 auto，而非硬编码数字
worker_processes auto; 是当前生产环境首选。Nginx 1.3.8+ 会自动读取 /proc/cpuinfo 中的逻辑核心数（含超线程），并在容器等受限环境中更可靠（如 Kubernetes 限制 2 核，nproc 输出即为 2，auto 会按此设置）。
- 避免手写
worker_processes 4;后迁移到 16 核机器却忘了改，导致长期性能浪费 - 在 NUMA 架构服务器上，auto 还能智能适配，减少跨节点内存访问开销
- 仅当有明确理由时才手动指定，例如混合部署时预留 CPU 给数据库：
worker_processes $(nproc --all)-2;
必须配套的关键参数
worker_processes 单独调高没用，必须和以下三项协同生效：
-
worker_cpu_affinity auto;：让每个 worker 固定绑定到专属 CPU 核，彻底杜绝迁移和缓存抖动（双核写
01 10，四核写0001 0010 0100 1000，或直接用 auto） - worker_rlimit_nofile 65536;：提升单个 worker 可打开文件数上限，否则即使进程数够，也会卡在 “too many open files”
- events 块中 worker_connections 10240;：该值 × worker_processes = 理论最大并发连接数，但需确保系统 ulimit -n ≥ 此乘积
验证是否真正起效
配置后不能只看 nginx -t 通过，要确认实际运行状态：
- 执行
ps -eo pid,psr,comm | grep nginx，查看各 worker 进程是否分散在不同 CPU 核（PSR 列数值应不重复） - 用
top -H -p $(pgrep -f "nginx: worker")观察各线程 CPU 占用是否均衡 - 压测时对比
cat /proc/$(pgrep nginx)/status | grepThreads，确认活跃线程数与 worker 进程数一致
