worker_processes 应设为物理核心数而非逻辑核数，需配合CPU绑定和系统级文件描述符调优；超线程对Nginx收益有限，auto仅在识别NUMA且避开超线程时可靠，容器等特殊场景须人工校准。
worker_processes 不是“开越多越好”，而是要让每个 worker 稳定运行在独立物理核心上，减少调度干扰和缓存抖动。连接性能提升的关键，不在于堆数量，而在于进程与硬件资源的精准匹配。
按物理核心数设置，别信逻辑核或 auto 的默认表现
超线程（如 32 物理核 + 64 逻辑 CPU）对 Nginx 这类 I/O 密集型服务收益有限，反而加剧 L1/L2 缓存争用和 TLB 刷新。盲目设为 64 容易引发上下文切换、惊群效应和内存浪费。
- 查清真实物理核心总数：用
nproc --all或lscpu | grep "Core(s) per socket"，再乘以 socket 数 - 推荐值：32 物理核 →
worker_processes 32；双路服务器需结合 NUMA 节点分布（如每节点 16 核，则分设两组） -
auto是便捷选项（Nginx 1.9.10+ 支持），但仅当确认它能识别 NUMA 且避开超线程对时才真正可靠
必须绑定 CPU，否则调优等于没做
只设对进程数不够，不绑定就无法让 SSL 缓存、共享内存锁、文件元数据等热点数据长期驻留本地缓存，跨核访问延迟会明显升高。
- 通用写法：
worker_cpu_affinity auto;（自动错开超线程对，优先分配物理核） - 精细控制示例（8 核）：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; - 禁止多个 worker 绑定同一物理核——否则绑定失效，还可能引发锁竞争
连接能力要同步放开，否则 worker 再多也跑不满
worker_processes × worker_connections 决定理论并发上限，但实际受系统级限制制约。常见瓶颈是 “too many open files” 报错或静默降级。
- 单 worker 连接数建议：2048～4096（静态资源可略高；动态接口建议保守些）
- 系统级 ulimit -n 至少 ≥
worker_processes × worker_connections，并预留 20% 给日志、上游连接等 - Nginx 配置中加：
worker_rlimit_nofile 65535;，并在/etc/security/limits.conf为 nginx 用户设硬限制
特殊场景需手动干预，auto 不万能
容器化、混合负载或高延迟上游等场景下，auto 会误读宿主机核数或忽略资源隔离，必须人工校准。
- 容器内限 2 核？显式写
worker_processes 2;，避免 auto 读到宿主机 64 核 - 与数据库共存？预留 1～2 核，设为
worker_processes $(nproc --all)-2; - 后端响应慢（如 API 平均 800ms）？可适度上浮至物理核数 ×1.2～1.5，但优先优化 upstream timeout 和重试策略
