Nginx 的 worker_processes auto 通过调用 sysconf(_SC_NPROCESSORS_ONLN)（等价于 nproc）获取系统可见逻辑 CPU 数启动 worker 进程，不识别 cgroup 限制，故容器中易失准，需结合验证与显式配置确保生效。
直接在 Nginx 主配置文件（通常是 /etc/nginx/nginx.conf）的最外层（即 main 块）写入 worker_processes auto; 即可。Nginx 启动时会自动读取系统报告的在线逻辑 CPU 数，并以此数量启动 worker 进程，无需手动计算或硬编码。
它怎么自动获取核心数？
Nginx 调用系统接口 sysconf(_SC_NPROCESSORS_ONLN)，等价于执行 nproc 命令的结果。这个值反映的是操作系统当前“可见”的逻辑 CPU 个数，比如：
- 一台物理机为 4 核 8 线程 → 返回 8
- Docker 容器限制为 2 核，但宿主机有 32 核 → 仍返回 32（不识别 cgroup 限制）
- OpenVZ 等旧虚拟化环境可能始终返回 1 → 上线前务必验证
为什么推荐用 auto 而不是固定数字？
硬编码如 worker_processes 4; 在多环境部署中容易失效：
- 开发机 2 核、测试机 4 核、生产机 32 核 → 配置需反复修改
- Kubernetes 中调整了
resources.limits.cpu→ worker 数未同步，导致资源争抢或浪费 - 云服务器升级规格后忘记改配置 → 无法利用新增核心
auto 让 Nginx 启动时自适应运行时环境，减少人工干预和配置漂移风险。
容器或资源受限场景要注意什么？
auto 在容器中容易失准，需额外处理：
- 显式指定更稳妥：例如容器限制为 2 核，就写
worker_processes 2; - 若坚持用
auto，建议搭配worker_cpu_affinity auto;（Nginx ≥ 1.12.0），减少跨核调度开销 - 混合部署（如 Nginx + Java 共存）可预留核心：通过启动脚本动态计算，如
worker_processes $(nproc --all | awk '{print $1-2}');
怎么确认配置真的生效了？
别只看配置文件，要验证运行态：
- 查错误日志：
tail -f /var/log/nginx/error.log，启动时会打印using X processes - 看实际进程数：
ps -C nginx --no-headers | wc -l（结果应等于配置值，含 master 进程） - 检查加载配置：
nginx -T 2>/dev/null | grep 'worker_processes'
