容器中 worker_processes 应设为实际分配的 vcpu 数（如 2），禁用 auto 模式，配合 worker_cpu_affinity auto 和按比例下调 worker_connections、rlimit_nofile 等参数以匹配资源限制。
在容器化环境中配置 worker_processes，不能照搬宿主机核数，必须以容器实际被分配的 vCPU 为准——否则会因进程数远超可用 CPU 资源，引发严重上下文切换和性能塌方。
先确认容器真实 vCPU 数量
容器内运行以下命令，避免被 /proc/cpuinfo 误导：
-
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us→ 若输出为200000 100000，说明配了 2 个 vCPU（200000 ÷ 100000 = 2） -
nproc在 cgroups v2 环境下通常返回准确值；若为 v1 且返回 1（如 OpenVZ 或旧版 Docker），需以 cgroup 计算结果为准 - Kubernetes 中严格对齐
resources.limits.cpu: "2"，即设worker_processes 2
明确禁用 auto 模式，显式设置数值
worker_processes auto; 在容器中风险极高：基础镜像若未适配 cgroups v2，会读取宿主机全部逻辑核数（比如宿主机 64 核，容器只分 2 核，却启动 64 个 worker）。
- Docker Compose 场景：在
nginx.conf中写死worker_processes 2;，值来自--cpus=2或cpus配置项 - K8s Deployment：用 Downward API 注入环境变量，在启动脚本中动态生成配置：
worker_processes ${NGINX_CPU_LIMIT:-2}; - 若使用 Nginx 官方镜像（≥1.21），可配合
envsubst实现模板化
绑定核心必须与 vCPU 分配一致
即使容器只分到 2 个 vCPU，Linux 仍可能将其调度在任意物理核上。需用 worker_cpu_affinity 锁定资源域：
- 推荐写法：
worker_cpu_affinity auto;（Nginx ≥ 1.9.10），它会自动跳过超线程对称核，仅在容器可见的 vCPU 范围内绑定 - 手动掩码示例（2 vCPU）：
worker_cpu_affinity 01 10;—— 前提是容器 cgroup 允许访问 CPU 0 和 1 - 若容器启用了
cpuset-cpus（如--cpuset-cpus="2,3"），则掩码应为0100 1000（对应 CPU 2 和 3 的位序）
配套参数必须按比例收紧
资源隔离后，文件描述符、连接数等上限也需同步降级，防止超出容器限制触发 OOM 或报错：
-
worker_rlimit_nofile 32768;（不高于容器ulimit -n设置） -
events { worker_connections 4096; use epoll; }→ 总并发上限 = 2 × 4096 = 8192，匹配 vCPU 能力 - 系统级 ulimit 必须在容器启动时注入：
ulimit -n 32768，或通过docker run --ulimit nofile=32768:32768
