nginx 的 worker_processes auto 在 docker 中失效，因其调用 sysconf(_sc_nprocessors_onln) 读取宿主机逻辑核数，不感知 cgroup cpu 配额限制；应显式设置 worker 数或结合 worker_cpu_affinity auto 缓解争抢，并通过 nginx -t -v、日志及 ps -o pid,psr,comm -c nginx 验证实际进程数与 cpu 绑定。
在 Docker 容器中，Nginx 的 worker_processes auto 常常无法准确识别可用 CPU 核数，导致启动时 worker 数量远超容器实际限制（比如宿主机 32 核，容器只分配了 2 核，却起了 32 个 worker），引发资源争抢、上下文切换飙升甚至 OOM。根本原因在于 Nginx 默认通过 sysconf(_SC_NPROCESSORS_ONLN) 获取在线 CPU 数——该系统调用**不感知 cgroups CPU 配额限制**，读取的是宿主机的核数。
确认是否真被 cgroups 限制了 CPU
进入容器内部，检查关键 cgroups 文件：
-
cat /sys/fs/cgroup/cpu.max（cgroup v2）：若输出类似200000 100000，表示限制为 2 核（200k us per 100k us period）；若为max，说明未限制 -
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us（cgroup v1）：计算quota / period得到等效核数，如100000 / 100000 = 1 -
nproc或getconf _NPROCESSORS_ONLN：这两个命令返回的仍是宿主机核数，不能代表容器真实可用核数
让 Nginx 感知容器 CPU 限制的几种方式
推荐按优先级使用以下方法之一，避免硬编码数字：
-
显式设置
worker_processes值：在启动容器时通过环境变量传入，并在 nginx.conf 中用env+set或模板生成配置。例如：docker run -e NGINX_WORKERS=2 ...，再用envsubst渲染 conf 文件 -
使用
worker_cpu_affinity auto（需 Nginx ≥ 1.19.10）：它虽不改变 worker 总数，但能自动将 worker 绑定到容器实际可调度的 CPU 上，缓解争抢 -
改用
worker_processes 1+ 多实例部署：更符合云原生理念，由编排层（如 Kubernetes）控制副本数，每个 Nginx 实例专注单核，规避识别问题
验证 worker 启动数量是否正确
不要只看 ps aux | grep nginx，要结合日志和运行时状态：
- 启动时加
-t参数测试配置：nginx -t -v会打印解析后的 worker 数（如using 2 worker processes） - 查看 master 进程启动日志：
docker logs <container> | grep "start worker process"</container>，统计实际 fork 出的 worker 数 - 运行中检查：
ps -o pid,psr,comm -C nginx（psr列显示绑定的 CPU ID），确认 worker 分布是否落在容器允许的 CPU 范围内
补充：Docker/K8s 场景下的典型配置建议
在生产环境中，应主动约束并显式声明：
- Docker：用
--cpus=2或--cpu-quota=200000 --cpu-period=100000限制，同时通过-e NGINX_WORKERS=2注入配置 - Kubernetes：在 Pod spec 中设置
resources.limits.cpu: "2"，配合 ConfigMap 或 initContainer 生成适配的 nginx.conf，或使用 sidecar 工具（如nginx-configurator）动态写入 - 避免依赖
auto：无论容器是否限制 CPU，都应显式指定 worker 数，既提升可预测性，也利于容量规划
