✅ 正确配置是worker_processes auto;，Nginx启动时调用sysconf(_SC_NPROCESSORS_ONLN)获取系统在线逻辑CPU数作为worker进程数，不识别cgroup限制、超线程开关或CPU隔离。
worker_processes auto; 本身就能让 Nginx Master 进程在启动时智能识别宿主机当前在线的逻辑 CPU 核心数，无需额外插件或脚本。它的“智能”体现在自动调用系统接口，但要注意：这个“智能”仅限于操作系统报告的可见逻辑核，不感知超线程开关、CPU 隔离（如 isolcpus）、cgroup 限制或 NUMA 拓扑。
✅ 正确配置方式
直接在 nginx.conf 的 main 块（最外层） 中写入：
worker_processes auto;
- 不是
worker_processes_auto on; - 不是
worker_processes = auto; - 不是放在
events或http块里——必须位于全局作用域
Nginx 启动时会执行等价于 nproc 命令的操作，即调用 sysconf(_SC_NPROCESSORS_ONLN)，读取 /proc/sys/kernel/nr_cpus 或内核运行时接口，得到一个整数，并据此 fork 对应数量的 worker 进程。
? 它到底识别什么？常见实际表现
| 环境示例 |
nproc 输出 |
worker_processes auto 启动的 worker 数 |
|---|---|---|
| 物理机：4 核 8 线程（超线程开启） | 8 |
8 |
| 物理机：4 核 4 线程（超线程关闭） | 4 |
4 |
| OpenVZ 虚拟机（旧环境） |
1（常固定） |
1 |
宿主机 32 核，但启用了 isolcpus=0-3
|
28（默认仍计入所有 online 核） |
28（不会自动跳过被隔离的核） |
⚠️ 注意：它不区分物理核/逻辑核，也不读取 lscpu 中的 Core(s) per socket；它只认内核标记为 “online” 的逻辑处理器。
? 如何确认它真的识别对了？
别只看配置文件，要验证运行态：
-
查看错误日志启动行：
tail -1 /var/log/nginx/error.log | grep "using.*processes" # 输出类似：nginx: [notice] using 8 processes
-
统计当前 worker 进程数（排除 master）：
ps -C nginx --no-headers -o pid= | wc -l # 应等于 nproc 输出值（即 auto 识别到的数）
-
对照系统命令：
nproc # 等价于 auto 获取的值 getconf _NPROCESSORS_ONLN # 同上，POSIX 标准接口
⚙️ 进阶建议：让识别更贴近真实负载需求
虽然 auto 能识别宿主机逻辑核数，但合理数量 ≠ 最大数量。可结合业务类型微调：
-
I/O 密集型（反向代理、静态文件）：通常设为物理核数更稳（例如 4 核机器，设
worker_processes 4;而非8），减少上下文切换； -
CPU 密集型（SSL 终结、gzip 压缩高并发）：可尝试
物理核数 × 1.2～1.5，再压测验证； -
NUMA 架构服务器（双路 CPU）：避免跨节点调度，建议设为单个 NUMA node 的逻辑核数（如
numactl --hardware查看）； -
混部场景（Nginx + Java 共存）：预留 2 核给其他服务，用启动脚本动态计算：
echo "worker_processes $(($(nproc) - 2));" > /etc/nginx/conf.d/override.conf
❌ 常见误区提醒
-
worker_processes auto;不等于“全自动最优”，它不优化，只适配； - 在容器中默认仍读宿主机核数，不是容器 vCPU 数（除非 Nginx ≥1.19.0 且 cgroups v2 正确暴露）；
-
worker_cpu_affinity auto;是配套指令（Linux only），可降低跨核调度开销，但它依赖worker_processes的值已合理——不能靠它“救”错配的进程数。
配置本身很简单，关键是理解它识别的是什么、在哪种场景下需要干预、以及如何验证是否真按预期运行。
