Nginx worker_processes应设为物理CPU核心数，而非逻辑核数；需结合CPU利用率、连接负载与上下文切换等运行时指标验证调优，并配套worker_cpu_affinity、ulimit-n等系统级限制调整。
直接看运行时表现，而不是只查配置文件里写了多少。worker 进程数配得不对，最常暴露在 CPU 利用率失衡、连接堆积、上下文切换频繁这三类现象上。
确认物理核心数，别被逻辑核数带偏
Linux 下 nproc 返回的是逻辑 CPU 数（含超线程），但 Nginx worker 是重量级进程，更适配物理核心。正确做法是：
- 查物理核心总数：lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)"，两者相乘即得
- 例如：2 路 CPU × 8 核/路 = 16 物理核 → 初始 worker_processes 16
- 若启用了超线程，逻辑核为 32，不建议直接设成 32；I/O 密集型场景可试 16～24，但必须压测验证
观察运行指标，识别失配信号
配完不等于调好，关键看三项实时指标：
- CPU 用户态使用率（top 中 %us）：持续 > 70% 且 worker_processes 较低 → 可增；已达物理核数仍高，说明瓶颈不在 worker 数量，而在 SSL、gzip 或上游响应
- 活跃连接与 worker 数比值：用 ss -s | grep estab 查当前 ESTABLISHED 连接数，再除以 worker 进程数；若单个 worker 平均承载远超 5000 连接，且延迟上升，说明连接分发过载
- 上下文切换（cs 字段）和进程调度延迟（pidstat -w）：worker 进程数明显超过物理核数时，cs 值突增、平均切换耗时升高，就是调度开销反噬性能的明确信号
验证是否真被 CPU 或 I/O 卡住
同一台机器上不同业务模式对 worker 需求差异很大：
- CPU 密集型（HTTPS 流量占比高、启用了大量 gzip 或 Lua 脚本）：建议 worker_processes 等于物理核数，并启用 worker_cpu_affinity 绑定核心，减少缓存失效
- I/O 密集型（静态文件服务多、反向代理为主、缓存命中率高）：worker_processes 1～4 常已足够；多进程主要提升中断响应和连接分发效率，不是为了榨干算力
- 混合型（HTTPS + 动态 upstream）：从物理核数起步，再用 wrk 对比 QPS 和 CPU idle 率微调；比如 16 核机器先设 16，压测后发现 idle 率仅 15% 但 QPS 不再增长，就说明该减了
检查系统级限制是否拖后腿
worker 进程数配对了，不代表就能跑满。常见“假匹配”问题：
- ulimit -n 太小：每个 worker_connections 都要占一个文件描述符；设了 worker_connections 16384，但 ulimit -n 还是默认 1024 → 新连接直接被拒绝
- 未调大系统级连接队列：/proc/sys/net/core/somaxconn 默认常为 128，而 Nginx listen 的 backlog 若设为 4096，实际生效的仍是 128，导致连接在内核队列就丢弃
- 容器环境误读 vCPU：Kubernetes Pod 里 worker_processes auto 可能读到节点总核数；应显式限定，如 worker_processes 4;，并配合 resources.limits.cpu: "4"
