worker_processes应设为CPU物理核心数，配合worker_cpu_affinity绑定可使每个worker独占一核，减少上下文切换与缓存失效；4核CPU典型配置为worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 容器中须与--cpuset-cpus对齐。
Nginx 的 worker_processes 和 worker_cpu_affinity 配合使用，是为了让每个 worker 进程独占一个 CPU 核心，减少上下文切换和缓存失效，提升高并发下的性能稳定性。
明确 worker_processes 数量与 CPU 核心数的关系
建议将 worker_processes 设为 CPU 物理核心数（非超线程数），尤其在启用 CPU 亲和性时。例如 4 核 CPU，通常设为：
worker_processes 4;
若设为 auto，Nginx 会自动读取核心数，但需确保系统未启用了 CPU 隔离（如 kernel 启动参数 isolcpus）或容器限制（如 Docker 的 --cpuset-cpus），否则可能误判。
worker_cpu_affinity 的配置格式要匹配进程数
每个二进制位代表一个逻辑 CPU（从左到右对应 CPU0、CPU1…），每组数字对应一个 worker 进程。4 个 worker 绑定到 4 个核心的典型写法是：
worker_cpu_affinity 0001 0010 0100 1000;
等价于：
worker_cpu_affinity 1 2 4 8;
注意：
- 位数总长应 ≥ 逻辑 CPU 总数（如 8 线程 CPU 可写 8 位，但只启用前 4 位也合法）；
- 进程数必须与掩码组数严格一致，否则 Nginx 启动失败并报错 invalid number of arguments in "worker_cpu_affinity"；
- 若用 worker_processes auto，则 worker_cpu_affinity auto 可自动按核心顺序绑定（Nginx 1.9.10+ 支持），更安全省心。
验证绑定是否生效
启动后可通过以下方式确认：
- 查 Nginx 主进程和 worker 进程的 CPU 亲和性：
taskset -cp <pid></pid>（例如ps aux | grep nginx | grep -v master | awk '{print $2}' | xargs -I{} taskset -cp {}） - 观察
/proc/<pid>/status</pid>中的CapBnd不相关，重点看voluntary_ctxt_switches和nonvoluntary_ctxt_switches—— 绑定合理时后者应明显低于未绑定场景； - 用
htop（F2 → Display options → 勾选 "Show custom thread names" 和 "Show CPU usage"）直观查看各 worker 是否稳定运行在指定 CPU 上。
常见误区与注意事项
不要跨 NUMA 节点随意绑定：多路服务器中，若 CPU0–3 属于 Node0，CPU4–7 属于 Node1，而内存仅插在 Node0，则绑定 worker 到 CPU4–7 可能引发远端内存访问延迟。应结合 numactl --hardware 规划亲和范围。
避免与系统关键进程争核：留至少 1 个核心给 OS、SSH、监控等，例如 8 核机器可设 worker_processes 7 并手动分配掩码，避开 CPU0。
容器环境需额外处理：Docker/K8s 中，worker_cpu_affinity 指的是容器视角的 CPU ID，须与 --cpuset-cpus="0-3" 对齐，且宿主机上该范围需真实可用。
