物理核心数是最优worker_processes值，需用lscpu查Core(s) per socket×Socket(s)得出，再据业务微调，并同步配置worker_rlimit_nofile、worker_connections和epoll及cpu亲和性。
直接设为物理核心数，是最有效、最省事的解法。别信“越多越好”，超了反而拖慢响应、空耗 CPU。
先确认你的真实物理核数
很多人误用 nproc 或 lscpu | grep "CPU(s)"，结果把超线程（逻辑核）当物理核。正确做法是：
- 执行
lscpu | grep "Core(s) per socket"和lscpu | grep "Socket(s)" - 两个数字相乘，才是可用物理核心总数（例如 2 sockets × 6 cores = 12 核）
- 容器中运行时，看
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us：若值为 200000（即 2 核配额），就只能设worker_processes 2 - 宝塔面板“系统信息”页显示的核数不可靠，它常把超线程算进去
按业务场景微调，不是死守“等于物理核”
物理核数只是起点，实际要结合业务特征调整：
- 长连接多（WebSocket/gRPC）：每个 worker 要维持数千连接，内存和文件描述符压力大，建议设为物理核数的 1/2～3/4（如 12 核 → 设 6 或 9）
- 静态文件服务 + HDD 或未开
sendfile：IO 成瓶颈，进程太多会加剧磁盘随机寻道，推荐 2～4 个（HDD）或最多 8 个（SSD） - 纯软件 SSL 加解密（无硬件加速卡）且 QPS 高：可比物理核多设 1～2 个，分担 CPU 计算压力
- Nginx 与 MySQL/PHP 混部：预留 1～2 核给其他服务，
worker_processes设为$(nproc --all) - 2
只改 worker_processes 还不够，必须同步调这三项
缺一不可，否则轻则无效，重则 Nginx 启动失败：
-
worker_rlimit_nofile：必须等于 Nginx 运行用户（如www）的ulimit -n值。在/etc/security/limits.conf中设好后，此处写相同数字（如 65535） -
worker_connections：放在events { }块内，建议按公式算：ulimit -n ÷ worker_processes × 0.9（留 10% 余量）。例如 ulimit 是 65535、worker_processes 是 6，则设 9830 -
use epoll;：显式写在events { }块里，Linux 下不写可能 fallback 到低效模型
加一层绑定，让每个 worker 真正独占一核
避免多个 worker 抢同一个 CPU 核，减少缓存失效和切换开销：
- 确保
worker_processes是明确数字（不能是auto），比如worker_processes 6; - 写
worker_cpu_affinity 000001 000010 000100 001000 010000 100000;（6 位掩码，每位对应一个核） - 8 核以上不想手算，可用
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持，自动跳过超线程，只绑物理核）
