容器中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 上
