worker_processes 应设为实际可用cpu物理核心数，而非逻辑核或超线程数；推荐使用 auto 并配合 worker_cpu_affinity 绑定核心，同时需同步调优 worker_connections、ulimit 和 numa 亲和性以避免性能下降。
worker_processes 不是设得越多越好，而是要匹配 CPU 实际可用核心数。设少了浪费算力，设多了反而因进程切换、锁竞争和内存开销拖慢整体性能。
优先用 auto，但得确认它读的是谁的核数
在 /etc/nginx/nginx.conf 的 main 块（最外层）写：
- worker_processes auto; —— 这是生产环境推荐写法，Nginx 会自动读取系统 CPU 核心数
- 但要注意：容器中运行时，
auto默认读的是宿主机核数，不是容器分配的核数。比如 Kubernetes 里限制了resources.limits.cpu: "2"，就必须显式写成 worker_processes 2; - 可通过
nproc --all命令确认当前环境可见的核心数，再决定是否手动设置
别超过物理核心数，尤其别盲目翻倍
Nginx 的 worker 是单线程异步非阻塞模型，一个进程就能高效处理上万连接。超核数配置常见问题：
- CPU 频繁上下文切换，消耗时间片
- 多个 worker 竞争监听套接字，触发“惊群效应”（虽有
accept_mutex缓解，但未根除） - 每个 worker 加载完整配置、缓存结构、连接池，内存占用线性增长
- 实测：8 核机器设为 16 个 worker，在高并发短连接场景下 QPS 反而下降 5%～15%
配合 CPU 亲和性，让每个 worker 跑在固定核心上
加这一行能减少缓存失效、提升指令级并行效率：
- 4 核机器示例：worker_cpu_affinity 0001 0010 0100 1000;
- 8 核机器示例：worker_cpu_affinity 00000001 00000010 ... 10000000;（共 8 组）
- 注意：该指令必须与
worker_processes数量一致，否则不生效
配套参数必须同步调，否则 worker 多了也撑不住
单独调 worker_processes 没用，下面三项要一起检查：
-
worker_rlimit_nofile：设为系统允许的最大文件描述符数（如
65535），避免 “Too many open files” 错误 -
events { worker_connections 10240; }：每个 worker 最大连接数，总并发 ≈
worker_processes × worker_connections -
ulimit -n：确保系统级限制 ≥
worker_rlimit_nofile，建议设为65535或更高
改完配置记得先 nginx -t 测试语法，再 nginx -s reload 平滑生效。
