Nginx的worker_processes auto仅依据操作系统报告的逻辑CPU数（如超线程后的总数），而非物理核心数；应结合lscpu查物理核心、容器内检查实际vCPU，并按I/O或CPU密集型负载合理设置，再通过error.log和ps验证生效值。
worker_processes auto; 并不直接识别物理 CPU 拓扑，它只读取操作系统报告的在线逻辑 CPU 数（即 /proc/cpuinfo 中 processor 字段总数），而非物理核心、插槽数或超线程状态。要获得真正适配硬件拓扑的 worker 数，必须结合系统命令人工判断，并在 auto 基础上做限制或覆盖。
看清物理核心数，别被超线程迷惑
Linux 下 nproc 返回的是逻辑核数（含超线程），不能直接用作 worker 进程数依据。应使用：
-
lscpu | grep "Core(s) per socket"查每路 CPU 的物理核心数 -
lscpu | grep "Socket(s)"查 CPU 插槽数 - 两者相乘得总物理核心数（例如 2×16 = 32 物理核）
若机器是 4 核 8 线程，auto 默认设为 8，但多数 I/O 密集型 Nginx 场景下，设为 4 更稳；若启用了 SSL 卸载或大量 gzip，可尝试 4～6，再通过压测确认。
容器与虚拟化环境需主动干预
在 Docker 或 Kubernetes 中，auto 仍可能读到宿主机全部逻辑核（如宿主机 64 核，容器仅分配 2 vCPU），导致进程数远超可用资源：
- 查容器实际可用 CPU：运行
cat /sys/fs/cgroup/cpuset/cpuset.cpus或nproc（容器内执行） - 云环境如 K8s Pod 设置了
resources.limits.cpu: "2"，应显式写worker_processes 2; - 若坚持用 auto，务必加兜底：配置中紧随其后写
worker_cpu_affinity auto;（Nginx ≥ 1.12.0），让每个 worker 尽量绑定到不同 vCPU
按业务类型微调初始值
物理核心数只是起点，最终数量取决于工作负载特征：
- I/O 密集型（静态文件、反向代理、缓存命中率高）：1～4 个 worker 往往已足够；多进程主要提升连接分发效率，不是拼算力
-
CPU 密集型（全站 HTTPS、实时 gzip、OpenResty Lua 大量计算）：可设为物理核心数，避免调度开销，但需监控上下文切换（
vmstat 1中 cs 列）是否激增 -
混合型或上游不稳定（如常连慢数据库）：从物理核数起步，观察
top中 %wa（I/O 等待）和 %us（用户态 CPU）占比，若 %wa 高而 %us 低，说明 worker 过多反而加剧争抢，应减少
验证生效值与运行状态
配置写完不等于生效，必须检查：
- 启动时看 error.log：
tail -f /var/log/nginx/error.log，会有类似using 4 processes的提示 - 查进程树：
ps -C nginx --no-headers | wc -l（master + workers 总数应匹配） - 运行中确认：
nginx -T 2>/dev/null | grep worker_processes显示加载的实际值 - 配合
worker_connections和worker_rlimit_nofile才能释放多进程潜力，否则并发能力受限于单进程瓶颈
