容器中worker_processes auto;会误读宿主机CPU数，应显式设为limits值或通过cgroups计算vCPU数；负载均衡场景推荐worker数≤2并配multi_accept与stub_status监控。

直接写 worker_processes auto; 在容器里通常会失效——它读的是宿主机的逻辑 CPU 数，不是容器实际能用的 vCPU。想让 auto 在负载均衡场景下真正“认对核”，得主动干预，不能只靠一句 auto。

为什么容器里 auto 会出错

nginx 启动时调用 sysconf(_SC_NPROCESSORS_ONLN)，返回的是操作系统当前在线的逻辑 CPU 总数。在 Docker 或 Kubernetes 中：

• 宿主机有 64 核，但 Pod 只分配了 resources.limits.cpu: "2"
• nginx 仍会启动 64 个 worker 进程
• 结果是大量进程争抢 2 个 vCPU，上下文切换暴涨，吞吐反而暴跌

正确识别容器内可用 vCPU 的方法

别依赖 auto 猜，要主动查、显式设或加兜底：

• 最稳妥：显式配置数值 —— 在 nginx.conf 中直接写 worker_processes 2;（与 K8s limits.cpu 一致）
• 次选：用 cgroups 接口查真实配额 —— 容器内执行：
  cat /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us 和 /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us，相除得 vCPU 数（如 200000/100000 = 2）
• 若坚持用 auto，必须加绑定兜底 —— 配置紧随其后：
  

  worker_processes auto;<br>
    worker_cpu_affinity auto;

  
  （要求 Nginx ≥ 1.12.0，且容器内能正确读取 cgroups）

负载均衡场景下的特别建议

反向代理类负载均衡器（如转发 OCR 请求、API 网关）通常 I/O 密集、计算轻，不需满配 worker：

• 即使容器被分配 4 vCPU，worker_processes 2; 往往更稳——避免因上游慢响应（如后端 OCR 服务延迟波动）导致 worker 长期阻塞、排队
• 配合 worker_connections 4096; 和 multi_accept on;，单 worker 处理能力已足够覆盖多数代理流量
• 开启 stub_status，监控 Waiting 连接数：若持续高于 1000，优先调大 worker_connections，而非增加 worker 数

验证是否生效

上线后必须检查，不能只信配置文件：

• 看错误日志：tail -f /var/log/nginx/error.log，启动行应显示 using 2 processes
• 查进程数：ps -C nginx --no-headers | wc -l（输出应为 1 个 master + N 个 worker）
• 查绑定情况：ps -eo pid,psr,comm | grep 'nginx:'，确认各 worker 分布在不同 CPU ID 上