worker_processes auto在容器中会误读宿主机CPU数，因其仅调用sysconf(_SC_NPROCESSORS_ONLN)探测系统在线逻辑核数，完全无视cgroup的vCPU限制，导致进程数远超分配资源，引发调度争抢、CPU节流甚至OOMKilled。
直接写 worker_processes auto; 在容器里会误读宿主机 CPU 数，不是“自动适配”，而是“自动探测”——它只看 sysconf(_SC_NPROCESSORS_ONLN) 返回的系统在线逻辑核数，完全无视 cgroups 对 vCPU 的限制。结果就是：宿主机 64 核、容器只分了 2 核，Nginx 却拉起 64 个 worker，引发严重调度争抢、CPU 节流，甚至被 OOMKilled。
为什么 auto 在容器里必然失效
根本原因在于 Nginx 启动时机早于容器运行时环境感知：
-
auto不解析/sys/fs/cgroup/cpu.cfs_quota_us或/sys/fs/cgroup/cpu.max - 不识别 Docker 的
--cpus=2或 K8s 的resources.limits.cpu: "2" - 旧版 Nginx（
三种可靠解法，按推荐顺序排列
别再赌 auto 能“猜对”，必须主动控制：
-
显式固定值（最稳）：在 nginx.conf 中直接写
worker_processes 2;，数值严格等于 Pod/容器的 CPU limit。K8s 场景下，和resources.limits.cpu保持一致，一步到位，零歧义 -
cgroup 动态计算（较灵活）：用 entrypoint 脚本启动前读取配额，例如：
QUOTA=$(cat /sys/fs/cgroup/cpu.max 2>/dev/null | awk '{print int($1/$2)}' | grep -E '^[0-9]+$')<br> [ -z "$QUOTA" ] && QUOTA=$(cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null | awk '{if($1>0) print int($1/100000)}')<br> echo "worker_processes $(($QUOTA > 0 ? $QUOTA : 1));" > /etc/nginx/conf.d/worker.conf -
auto + affinity 强约束（次选）：仅当无法改启动流程时用，需 Nginx ≥1.12：
worker_processes auto;<br> worker_cpu_affinity auto;
它不能修正进程总数，但可强制每个 worker 绑定不同逻辑核，缓解争抢——前提是 worker 数 ≤ 实际可用 vCPU，否则仍无效
上线前必须验证的三件事
配置写了不算数，得看运行态是否真实生效：
- 查错误日志：
tail -f /var/log/nginx/error.log，启动行应明确打印using 2 processes（数字要和你预期一致） - 看真实进程数：
ps -C nginx --no-headers | wc -l，输出应等于worker_processes值（注意：包含 1 个 master 进程） - 确认加载配置：
nginx -T 2>/dev/null | grep 'worker_processes'，排除模板未渲染、conf.d 未 include 等低级错误
配套必须调的参数
只改 worker_processes 是单点优化，必须同步收紧资源边界：
-
worker_rlimit_nofile设为容器内 ulimit -n 值（如 65535），防止 open files 报错 -
events { worker_connections 4096; use epoll; }，其中worker_connections建议按ulimit -n ÷ worker_processes × 0.9计算 - 负载均衡类场景（如 API 网关），即使分配了 4 vCPU，也建议
worker_processes 2;—— I/O 密集型任务更依赖单 worker 吞吐，而非堆数量
