worker_processes auto 实际读取的是操作系统标记为“online”的逻辑cpu总数，即调用sysconf(_sc_nprocessors_onln)或执行nproc命令的结果，不区分物理核与超线程、不感知numa、不识别cgroup限制。
worker_processes auto 不是“智能调度”，而是启动时一次性读取系统当前在线逻辑 CPU 数，并据此派生对应数量的 worker 进程。
它实际读的是什么？
nginx 启动时调用 sysconf(_SC_NPROCESSORS_ONLN)，等价于容器或宿主机中执行 nproc 命令的结果——即操作系统标记为 “online” 的逻辑 CPU 总数。这个值：
- 不区分物理核与超线程（HT）逻辑核
- 不感知 NUMA 节点分布
- 不主动识别 cgroup 限制（如 Docker 的
--cpus=2或 K8s 的resources.limits.cpu） - 在容器中是否受限，取决于内核版本、cgroups 版本及 nginx 版本支持程度（≥1.19 才开始尝试从 cgroups 读取）
为什么说它只是探测，不是自适应？
auto 仅在 nginx master 进程启动瞬间执行一次，之后 worker 数量固定不变。它不会：
- 随负载升高/降低动态增减进程
- 根据请求类型（静态文件 or Lua 计算）调整策略
- 感知 I/O 等待率或上下文切换开销而回退
换句话说：它设的是“起点”，不是“闭环反馈控制器”。真正的调优仍需人工结合监控（如 vmstat 1 中的 cs 和 %wa）、业务特征与部署环境判断。
auto 在不同环境下的行为差异
同一行配置，在不同场景下可能产生完全不同的效果：
- 裸机部署：通常准确反映可用逻辑核数，可直接使用
- Docker/K8s 容器：若未显式限制 CPU 或镜像内核/nginx 版本过旧，可能读到宿主机全部核心（如宿主机 64 核，容器只分到 2 vCPU），导致启动 64 个 worker，引发争抢甚至 OOMKilled
-
VM 或云实例：取决于虚拟化层是否正确暴露拓扑信息；部分云厂商虚拟 CPU 并不一一映射物理核，
nproc结果可能失真
如何验证 auto 是否按预期生效？
三步快速确认：
- 查 nginx 版本：
nginx -v，确保 ≥1.19（推荐 ≥1.21） - 进运行中的 nginx 容器或服务器，执行
ps aux | grep 'nginx: worker'，统计进程数 - 对比
nproc输出 —— 若一致，说明 auto 生效；若远大于容器cat /sys/fs/cgroup/cpuset/cpuset.cpus显示的 CPU 列表长度，则说明未受 cgroup 限制影响，需手动干预
