worker_processes应设为cpu逻辑核心数（推荐auto），超核数会引发上下文切换和惊群效应，不足则浪费资源；需配合worker_cpu_affinity绑核及ulimit、worker_rlimit_nofile等系统参数协同调优。
Nginx 的 worker_processes 不是“越多越好”，也不是“随便设个数就行”。它直接决定有多少个独立工作进程并行处理请求，而每个进程默认绑定一个 CPU 核心运行。配得准，多核才真正发力；配错了，要么闲置资源，要么引发调度内耗。
worker_processes 应等于逻辑 CPU 核心数（推荐用 auto）
Linux 下执行 nproc 可查实际可用逻辑核数（含超线程）。4 核 8 线程机器，通常设为 8；但若负载偏重计算或缓存敏感（如静态服务），优先按物理核数设（即 4）更稳。配置写法：
-
worker_processes auto;—— Nginx 1.3.8+ 支持，自动读取并设置，适合大多数物理机和明确分配 vCPU 的容器环境 -
worker_processes 4;—— 显式指定更可控，尤其在 Kubernetes 中设置了resources.limits.cpu: "2"时，必须手动设为2，否则auto会误读宿主机核数，导致静默降级为单核运行
设太大或太小都会掉性能
- 设为
1：所有请求串行排队，高并发下响应延迟飙升，CPU 利用率却可能很低 - 设为
16（在 8 核机器上）：进程调度开销上升，上下文切换频繁，锁竞争加剧，实测 QPS 反而下降 5%～15%，尤其在短连接 API 场景中更明显 - 容器或云主机中，
/proc/cpuinfo显示的核数不可信，务必以nproc输出为准
必须配合 worker_cpu_affinity 绑核才有效
光设对进程数还不够——默认情况下，多个 worker 进程可能被内核调度到同一个 CPU 核上。启用绑核可避免跨核迁移、减少 L2 缓存失效：
- 四核机器：
worker_cpu_affinity 0001 0010 0100 1000; - 八核机器（推荐）：
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持） - 注意：若容器只分到 2 个 vCPU，
worker_cpu_affinity必须只写两组掩码（如01 10），否则 Nginx 启动失败或退化运行
别忘了配套调系统与 Nginx 资源上限worker_processes × worker_connections 是理论并发上限，但实际受三重限制：
- 系统文件描述符：
ulimit -n 65536（需在 nginx 启动前生效） - Nginx 单进程上限：
worker_rlimit_nofile 65536;（写在 main 块） - 每个 worker 最大连接数：
events { worker_connections 4096; }
三者不匹配，会出现accept() failed (24: Too many open files)错误
不复杂但容易忽略
