最稳妥起点是 worker_processes auto，但需同步配置 CPU 绑定、文件描述符扩容和连接数匹配；应按物理核心数设置进程数，禁用超线程逻辑核，配合 worker_cpu_affinity auto 和 ulimit、worker_rlimit_nofile、worker_connections 等调优。
直接设 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 全挤到同一个核上，造成缓存抖动和频繁上下文切换。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 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、gRPC、上游响应慢）：建议设为物理核数的 1/2～3/4（如 16 核设 8～12）
- 资源共用服务器（Nginx 和数据库同机）：预留 1～2 个核，
worker_processes可设为$(nproc --all) - 2
