物理核心总数 = socket(s) × core(s) per socket，lscpu中这两字段语义清晰、稳定可靠；/proc/cpuinfo的cpu cores和physical id需谨慎使用，nproc和getconf返回逻辑核数易误导。
直接设为物理 CPU 核心数最稳妥，不建议盲目堆高或依赖逻辑核数量。
看准真实物理核心，别被超线程迷惑
Linux 下用 lscpu | grep "Core(s) per socket" 和 lscpu | grep "Socket(s)" 相乘，得到物理核心总数。比如 2 路 CPU × 12 核/路 = 24 物理核，初始就设 worker_processes 24。超线程（HT）带来的逻辑核（如 48 个）不作为依据——Nginx worker 是重量级进程，绑定物理核更稳，缓存效率更高。
优先用 auto，但要加限制兜底
worker_processes auto; 是推荐起点，它会读取 /proc/cpuinfo 自动适配。但在云环境或容器中，宿主机可能暴露过多 vCPU（比如标称 32vCPU，实际共享资源），这时 auto 可能设得偏高。稳妥做法是：
- 生产配置里写 worker_processes auto;
- 同时在同级配置加注释或配套监控，必要时显式限定上限，例如 worker_processes 16;（适用于中等负载的 24 核机器）
结合业务类型微调
不是所有场景都要填满物理核：
- I/O 密集型（静态文件、反向代理、缓存命中率高）：常 1～4 个 worker 就够用，多进程主要提升连接分发和中断响应，不是拼算力
- CPU 密集型（大量 HTTPS 加解密、gzip 压缩、OpenResty 中 Lua 运算）：建议设为物理核数，避免上下文切换浪费
- 混合型（HTTPS + 动态 upstream）：从物理核数起步，再用 ab 或 wrk 测 QPS，同时观察 top 中 %us 和 nginx -s reload 后的活跃连接分布
必须同步检查系统与 Nginx 的连接限制
worker_processes 单独调高没用，得和连接能力匹配：
- 在 events { } 块里设 worker_connections 4096;（常见值，可按需上调）
- 全局块加 worker_rlimit_nofile 65535;，且该值必须大于 worker_connections
- 检查系统级限制：ulimit -n，若低于 65535，需在 /etc/security/limits.conf 中补充：
* soft nofile 65535
* hard nofile 65535
并确认 Nginx 启动时生效（非仅当前 shell）
