worker_processes 应设为 CPU 逻辑核心数（推荐 auto），配合 worker_cpu_affinity 绑定核心以减少缓存失效；启用 reuseport 可规避惊群问题；需同步调优 worker_connections 与系统文件描述符限制。
设置合适的 worker_processes 值，确实能减少 Nginx 进程间的资源争用，但关键不在于“越多越好”或“越少越好”，而在于匹配 CPU 核心数与工作负载特征。
worker_processes 与 CPU 核心数对齐
Nginx 的每个 worker 进程是单线程、事件驱动的，通常一个进程绑定一个 CPU 核心最有效。若设为 auto（推荐），Nginx 启动时会自动读取系统可用逻辑 CPU 数并设为对应值；手动设置时，一般不应超过物理核心数（超线程可酌情考虑，但收益有限）。
- 多核机器上设为
1：所有请求挤在一个进程里，无法利用并行能力，容易成为瓶颈 - 设为远高于 CPU 核心数（如 32 核设 64）：引发频繁上下文切换和锁竞争（例如共享内存、accept 锁、缓存锁），反而降低吞吐
-
auto是生产环境首选，既适配容器/CPU limit 场景，也避免人为误判
配合 worker_cpu_affinity 提升缓存局部性
仅调 worker_processes 不够，还需让每个 worker 固定运行在指定 CPU 核心上，减少跨核缓存失效（cache miss）和迁移开销。
- 启用方式示例：
worker_cpu_affinity auto;（1.9.10+）或显式配置如worker_cpu_affinity 0001 0010 0100 1000; - 效果明显体现在高并发短连接场景（如 API 网关），延迟抖动下降、L3 缓存命中率上升
- 注意：Docker/K8s 中需确保容器有明确的 CPU 绑定（
--cpuset-cpus），否则内核调度可能绕过 affinity 设置
避免 accept 锁与惊群问题干扰进程协作
多个 worker 共享监听端口时，旧版本 Nginx 存在“惊群”（thundering herd）问题——新连接到来时所有 worker 都被唤醒竞争 accept，造成无效唤醒和锁争用。
- 1.9.1+ 默认开启
accept_mutex on（且不可关闭），由一个 worker 负责 accept，其余等待，大幅降低锁冲突 - 若使用
reuseport（Linux 3.9+，需编译时支持），可在内核层面分发连接到不同 socket，彻底规避用户态锁，此时accept_mutex自动失效，推荐高并发场景启用 - 验证是否生效：查看
netstat -ltnp | grep :80，若有多个相同端口对应不同 PID，说明 reuseport 已启用
结合 worker_connections 控制单进程承载能力
worker_processes × worker_connections 决定了理论最大并发连接数，但过高设置可能因内存/文件描述符不足导致失败，而非单纯“降低竞争”。
- 每个连接约占用 2–3 KB 内存（取决于 SSL、buffer 大小等），10K 连接 ≈ 20–30 MB 内存/worker
- 务必同步调整系统级限制：
ulimit -n、/etc/security/limits.conf、fs.file-max - 观察指标：用
nginx -t && nginx -s reload后检查ps aux | grep nginx进程数，并用ss -s或netstat -an | wc -l对比实际连接分布
