worker_processes 应设为 cpu 物理核心数或 auto，容器环境须手动指定以匹配实际 vcpu 数，避免超核引发上下文切换、惊群效应及“too many open files”错误，需协同 worker_cpu_affinity、worker_rlimit_nofile 等参数联动调优。
worker_processes 是 Nginx 并发能力的起点，但它不是“越多越好”，而是要和 CPU 实际可用核心数、业务 IO 特性、系统资源限制匹配。配错它，轻则浪费资源，重则引发上下文切换风暴、惊群效应，甚至出现 [alert] socket() failed (24: Too many open files) 这类错误。
worker_processes 怎么设才合理
这个参数必须放在 main 块（配置文件最外层），决定启动多少个独立 worker 进程。每个进程都能并发处理成千上万连接，关键在于“够用且不冗余”：
-
推荐写法是
worker_processes auto;——Nginx 自动读取系统 CPU 物理核心数（不含超线程），适合绝大多数物理机或虚拟机环境 -
容器场景必须手动指定：比如 Kubernetes 中容器只分配了 2 核，就该写
worker_processes 2;，否则 auto 会读到宿主机核数，导致进程数虚高 -
混合部署时可适度预留：若同一台机器还跑着数据库或 Java 应用，建议设为
$(nproc --all) - 1或- 2，避免争抢 CPU - 别盲目堆数量：64 核服务器设 64 个 worker，反而因调度开销和内存碎片降低 QPS；实测 8～12 个常比满核更稳
必须配套调的几个关键参数
worker_processes 不是单打独斗，它和以下参数形成联动关系，缺一不可：
-
worker_cpu_affinity auto;：自动绑定每个 worker 到不同 CPU 核，减少跨核缓存失效，提升 L1/L2 缓存命中率 -
worker_rlimit_nofile 65535;：让每个 worker 进程能打开足够多的文件描述符，值需与系统ulimit -n一致（否则再大也无效） -
events { use epoll; multi_accept on; }：Linux 下必须用 epoll，multi_accept on允许单次事件循环尽可能多地接收新连接，缓解突发流量冲击
并发上限怎么算，又怎么防超限
理论最大并发 = worker_processes × worker_connections，但真实可用值受三重制约：
-
系统级限制：/etc/security/limits.conf 中需设置
* soft nofile 65535和* hard nofile 65535，并确保 systemd 启动时加载（如通过LimitNOFILE=65535） - 内存占用：每个连接约消耗 2–4 KB 内存，若设 8 个 worker × 65535 连接，仅连接结构体就占近 2 GB 内存，需按实际内存反推合理值
- 上游瓶颈：如果后端响应慢，worker 被长时间阻塞，再多进程也无济于事——此时应优先优化 upstream 的 keepalive、timeout 和重试策略，而非加 worker
什么情况下可以略超核心数
纯 CPU 密集型任务（如大量 SSL 加解密、gzip 压缩）确实适合 worker 数 ≈ 物理核心数；但多数 Web 场景属于 I/O 密集型，少量超配可能有益：
-
高延迟上游依赖：比如大量请求需等待外部 API 或慢速 DB，可设为
core_count × 1.2，缓解阻塞积压 - 短连接 + 极高新建速率：如 CDN 回源或秒杀入口，连接建立/断开频繁，适当增加 worker 可分摊 accept 压力
-
注意边界：超配幅度建议 ≤ 20%，且必须同步验证
top中的 %sy（内核态 CPU）是否明显升高——若升高，说明上下文切换已成瓶颈，应回退
