推荐设为 worker_processes auto;，但需结合物理核心数、cpu 绑定（worker_cpu_affinity auto;）、ulimit -n 与 worker_rlimit_nofile 扩容、worker_connections 匹配及 use epoll; 启用，才能真正用满多核性能。
直接设为 worker_processes auto; 是最稳妥的起点，但要真正用满多核性能，必须同步做好 CPU 绑定、文件描述符扩容和连接数匹配——单改这一项，几乎没用。
先确认该用几个进程
核心原则是：每个 worker 进程应独占一个物理 CPU 核心，而非逻辑核（超线程带来的额外核）。因为 Nginx worker 是重量级进程，共享 L1/L2 缓存，绑在同一物理核的两个逻辑核上反而容易互相干扰。
- 查物理核心总数：lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘即得（例如 2 sockets × 8 cores = 16 物理核）
- 查逻辑核数仅作参考：nproc 或 lscpu | grep "CPU(s):"
- 常见误区：32c64t 机器不建议直接设为 64；起点优先按 32 物理核来配
- 容器或 K8s 中，必须以 Pod 实际分配的 vCPU 数为准（如 limits.cpu: "4" → 就设 worker_processes 4;），auto 可能误读宿主机核数
必须绑定 CPU 核心
不绑定，系统调度器可能把多个 worker 全挤到同一个核上，造成缓存抖动和频繁上下文切换。
- Nginx ≥ 1.9.10 推荐写：worker_cpu_affinity auto; —— 它会自动跳过超线程对称核，优先绑定物理核
- 若需手动控制（如四核）：worker_cpu_affinity 0001 0010 0100 1000;（二进制位从右往左对应 core 0,1,2,3）
- 验证是否生效：ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同编号的 CPU 上
配套放开系统与 Nginx 资源上限
worker_processes × worker_connections 才是理论并发上限，但三处卡点常导致“配置了也跑不满”：
- 系统级文件描述符限制：ulimit -n 65536（临时）；永久生效需在 /etc/security/limits.conf 中加：
nginx soft nofile 65536
nginx hard nofile 65536 - Nginx 内部声明上限：worker_rlimit_nofile 65536;（写在 main 块）
- 每个 worker 最大连接数：events { worker_connections 4096; }（建议 2048–8192，视内存和业务类型调整）
- 别漏掉事件模型：use epoll;（Linux 必须显式启用）
按业务类型微调数值
物理核数只是起点，最终值要看实际负载特征：
- I/O 密集型（静态文件、高命中反向代理）：通常 1～4 个 worker 就够，再多收益递减
- CPU 密集型（全站 HTTPS、OpenResty + Lua 计算）：可设为物理核数，但要监控 vmstat 1 中的 cs（上下文切换）是否异常升高
- 混合或长连接场景（WebSocket、上游响应慢）：建议设为物理核数的 1/2～3/4（如 16 核设 8～12）
- 与数据库等共用服务器：预留 1～2 核，worker_processes 可设为 $(nproc --all) - 2
