最稳妥起点是设 worker_processes auto，但需结合物理核心数、CPU亲和性、文件描述符限制和事件模型协同优化：先用lscpu确认真实物理核数，避免超线程干扰；启用worker_cpu_affinity auto或手动绑定；调高nofile限制并显式配置use epoll；再按I/O或CPU密集型等场景微调worker数量。
直接设 worker_processes auto; 是最稳妥的起点，但要真正发挥多核性能，不能只改这一项——必须结合物理核心数、CPU 亲和性绑定、文件描述符限制和事件模型协同调整。
先确认真实物理核心数，不是逻辑核
超线程（HT）会让一个物理核暴露成两个逻辑 CPU，比如 8 物理核 + HT = 16 逻辑核。但 Nginx worker 是重量级进程，绑在同一物理核的两个逻辑核上容易争抢缓存、抬高延迟。
- 查物理核心总数：
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘即得（如 2 sockets × 12 cores = 24 物理核） - 查逻辑核数仅作参考：
nproc或lscpu | grep "CPU(s):" - 容器或 K8s 中，以
nproc --all输出为准——若 Pod limits.cpu: "4"，就按 4 核配，auto可能误读宿主机 64 核导致静默降级
必须绑定 CPU 亲和性，否则调对也白搭
不绑定时，Linux 调度器可能把多个 worker 全挤到一个核上，频繁迁移导致 SSL 缓存失效、L2 预热归零、上下文切换飙升——实测 QPS 可跌 5%～15%。
- Nginx ≥ 1.9.10 推荐写：
worker_cpu_affinity auto;，它会自动跳过超线程对称核，优先绑定独立物理核 - 手动绑定示例（4 核物理机）：
worker_cpu_affinity 0001 0010 0100 1000;（位图从右往左对应 core 0–3） - 验证是否生效：
ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同 CPU 编号上
同步放开资源上限，避免“有核无粮”
worker_processes × worker_connections 是理论并发上限，但三处卡点常让配置形同虚设：
- 系统级文件描述符：在
/etc/security/limits.conf加两行：nginx soft nofile 65536nginx 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、实时 gzip 压缩、OpenResty 中大量 Lua 运算）：可设为物理核数，但要监控
vmstat 1中的cs（上下文切换）是否异常升高 - 混合或长连接场景（WebSocket、gRPC、上游响应慢）：建议设为物理核数的 1/2～3/4（如 16 核设 8～12）
- 资源共用服务器（Nginx 和数据库同机）：预留 1～2 个核，
worker_processes可设为$(nproc --all) - 2
