worker_processes 应设为cpu逻辑核心数，推荐使用auto；设过小导致多核闲置，过大引发调度开销与缓存失效，需配合worker_cpu_affinity绑定核心并调高ulimit-n以释放并发潜力。
worker_processes 是 Nginx 性能调优的起点，它不是“越多越好”，而是要与 CPU 实际可用资源精准匹配。设得太小，多核闲置；设得太大，反而因调度竞争拖慢整体响应。
worker_processes 应该设多少？
推荐直接使用 worker_processes auto; —— Nginx 1.3.8+ 版本支持该指令，会自动读取系统逻辑核心数（含超线程），比如 4 核 8 线程的机器就启动 8 个 worker 进程。若需手动确认，可在终端运行：
nproc 或 lscpu | grep "CPU(s):"
注意：云环境或容器中，/proc/cpuinfo 可能不准，以 nproc 输出为准。
为什么不能随便设高？
- 设为 1：所有请求串行排队，单核打满，其余核心空转，高并发下延迟飙升
- 设为远超核心数（如 16 个进程跑在 4 核机器上）：进程频繁切换、锁竞争加剧、缓存失效增多，实际吞吐反而下降
- 虚拟机或容器里盲目照搬物理机配置：vCPU 分配可能受限，需按实际分配数设置
必须配合 worker_cpu_affinity 使用
光设对进程数还不够。启用 worker_cpu_affinity 能把每个 worker 绑定到指定 CPU 核心，减少跨核迁移和 L2/L3 缓存失效。例如：
- 双核：worker_cpu_affinity 01 10;
- 四核：worker_cpu_affinity 0001 0010 0100 1000;
- 更简洁写法（Nginx 1.9.10+）：worker_cpu_affinity auto;
绑定后，每个 worker 稳定运行在专属核心上，缓存局部性更好，QPS 提升在高负载下尤为明显。
别忘了配套调整系统限制
worker_processes × worker_connections 才是理论最大连接数，但真正卡住你的往往是系统级瓶颈：
- 检查当前限制：ulimit -n
- 临时提升：ulimit -n 65536（需在 nginx 启动前执行）
- 永久生效：在 /etc/security/limits.conf 中为 nginx 用户添加：
nginx soft nofile 65536
nginx hard nofile 65536 - 同时建议配置 worker_rlimit_nofile 65536;，让 worker 进程明确知道能打开多少文件描述符
