最有效提升Nginx并发能力的是合理设置worker_processes和worker_connections。worker_processes应按物理核数设定并绑定CPU（如worker_cpu_affinity auto），避免超线程干扰；worker_connections需与系统ulimit -n同步调高，并配合epoll、multi_accept、accept_mutex等事件优化。
直接设对 worker_processes 和 worker_connections 是提升 Nginx 并发能力最有效、也最容易被忽视的两步。关键不在堆数量，而在让每个 worker 稳定运行在独立物理核心上，并配足连接资源。
worker_processes：按物理核数设，别信逻辑核或 auto 的默认表现
Nginx 是 I/O 密集型服务，超线程（如 32 物理核 + 64 逻辑 CPU）带来的收益极小，反而加剧缓存争用和 TLB 刷新。盲目设为逻辑核数，容易引发上下文切换、惊群效应和内存浪费。
- 查真实物理核心总数：
nproc --all或lscpu | grep "Core(s) per socket"× socket 数 - 双路服务器需考虑 NUMA：例如每节点 16 核，建议分设两组，避免跨节点访问延迟
-
worker_processes auto;仅在确认它能识别 NUMA 且避开超线程时才可靠；容器、混合负载等场景必须人工校准（如容器限制 2 核，就写worker_processes 2;）
必须绑定 CPU：否则调优等于白做
只设进程数不绑定 CPU，SSL 缓存、共享内存锁、文件元数据等热点数据无法长期驻留本地缓存，跨核访问延迟明显升高。
- 通用写法：
worker_cpu_affinity auto;（Nginx 1.9.10+，自动错开超线程对，优先分配物理核） - 精细控制示例（8 物理核）：
worker_cpu_affinity 00000001 00000010 ... 10000000; - 禁止多个 worker 绑定同一物理核——否则绑定失效，还可能引发锁竞争
worker_connections：要与系统级限制同步放开
理论并发上限 = worker_processes × worker_connections，但实际受系统文件描述符限制制约。常见报错 “too many open files” 或静默降级，往往就卡在这一步。
- 单 worker 连接数建议：静态资源可设 4096；动态接口（如 API）建议保守些，2048～4096 更稳
- 系统级
ulimit -n至少 ≥worker_processes × worker_connections，并预留 20% 给日志、上游连接等 - Nginx 配置中加：
worker_rlimit_nofile 65535;；同时在/etc/security/limits.conf为 nginx 用户设硬限制
配套事件模型优化不能少
光调两个参数不够，还得配合 Linux 高效事件机制才能真正跑满：
-
use epoll;（Linux 必开，比 select/poll 高效得多） -
multi_accept on;（每次唤醒 worker 时尽可能多地接受新连接，减少空转） -
accept_mutex on;（防止多 worker 同时争抢 accept，缓解惊群效应）
