worker_processes 应设为物理cpu核心数或使用auto，而非逻辑核数；需配合worker_cpu_affinity绑定核心、调高ulimit和worker_rlimit_nofile，并在容器或混合部署场景下手动调整以避免调度开销与资源争用。
worker_processes 是 Nginx 高并发模型的基石参数，它直接决定并行处理请求的进程数量，而非线程数或连接数。它的作用不是“越多越好”，而是要在硬件资源与调度开销之间取得平衡。
worker_processes 决定多进程调度结构
Nginx 采用 1 个 master 进程 + N 个 worker 进程 的架构。master 负责管理配置加载、平滑重启、信号转发；所有实际的网络 I/O、HTTP 解析、反向代理等任务，均由 worker 进程完成。每个 worker 是独立的、单线程、事件驱动的进程，能高效处理成千上万并发连接（依赖 worker_connections 和 epoll 等机制）。
- 每个 worker 进程绑定一个 CPU 核心（配合
worker_cpu_affinity效果更佳），避免跨核缓存失效 - 所有 worker 共享监听 socket（如
:80），由内核或 Nginx 自身协调 accept（accept_mutex控制争抢） - 请求进来后，由某个 worker 接收、解析、转发、响应，全程不阻塞、不创建新线程
它如何影响高并发表现
- ✅ 设得太小（如 1 个 worker）：无法利用多核 CPU，CPU 利用率低，QPS 上不去，尤其在多核机器上明显成为瓶颈
- ❌ 设得太大（如 64 核设 64 个 worker）：
- 进程间上下文切换频繁，消耗 CPU 时间片
- 每个 worker 加载完整配置、缓存、连接结构体 → 内存占用线性增长
- 即使启用
accept_mutex，惊群效应仍可能在高并发短连接场景下引发锁竞争
- ? 实测表明：8 核机器设
worker_processes 8，QPS 通常比设为 16 高 5%～15%；64 核服务器反而推荐8或12，而非64
正确设置的关键逻辑
- 默认推荐
worker_processes auto;—— Nginx 自动读取系统可用 CPU 核心数（注意：容器中需警惕，auto读的是宿主机核数） - 容器环境必须显式设置，例如 Kubernetes 中限制了
resources.limits.cpu: "4"，就应写worker_processes 4; - 混合部署时（如同时跑数据库+Java 应用），可预留核心：
worker_processes $(nproc --all)-2;（需脚本支持） - 不是孤立参数：必须同步配置
-
worker_rlimit_nofile（匹配系统ulimit -n） -
worker_cpu_affinity auto或手动绑定（提升 CPU 缓存命中率） -
events { use epoll; multi_accept on; worker_connections 16384; }
-
不复杂但容易忽略。
