worker_processes 应设为 CPU 物理核心数或 auto，避免超核引发上下文切换与缓存失效；需配合 worker_connections、worker_rlimit_nofile 及系统 ulimit -n 协同调优，容器环境须按 cgroups 实际配额动态设置。
Nginx 进程配置的核心在于让工作进程数量、系统资源与实际负载三者匹配，而不是盲目堆高数值。配得准，比配得多更重要。
worker_processes 设置原则
这个参数决定 Nginx 启动多少个独立的工作进程来处理请求。它不是越多越好，而是要贴合 CPU 物理核心数：
- 推荐设为 auto：Nginx 会自动读取 CPU 核心数并设置对应进程数，适用于绝大多数场景
- 若需手动指定，8 核服务器设为 8，16 核设为 16；超线程（如 8c16t）一般仍按物理核数设，避免上下文切换开销
- 不建议设为 1（除非调试或极低负载），也不建议超过物理核心数太多（如 32 核机器设 64），反而可能降低缓存命中率
worker_connections 与系统限制协同
每个工作进程能同时处理的连接数由 worker_connections 控制，但它受限于操作系统级的文件描述符上限：
- 在
events { }块中设置，常见值为 1024、4096 或 8192 - 必须确保
worker_rlimit_nofile（全局块）大于该值，例如设为 8192 或 65536 - Linux 下还需检查系统级限制：
ulimit -n，必要时在/etc/security/limits.conf中提升
内存与连接的实际开销估算
每个连接约占用 256 字节内存（不含请求体），便于评估整体内存压力：
- 8 个工作进程 × 8192 连接 ≈ 16MB 内存用于连接结构体
- 若启用 SSL/TLS 或大量长连接，需额外预留内存
- 静态资源服务场景可适当调高连接数；反向代理后端延迟高时，应更关注超时和队列控制，而非单纯加连接数
容器环境下的自动调优要点
Docker 环境中，宿主机 CPU 核心数未必等于容器可见核数，需依赖入口点脚本适配：
- 官方镜像（如
nginx:alpine）自带30-tune-worker-processes.sh，会根据cgroups信息动态设worker_processes - 若使用
docker run --cpus=2限制 CPU，确保基础镜像支持该检测逻辑，或显式传入环境变量覆盖 - 避免在 Dockerfile 中硬编码
worker_processes 4，否则在单核容器里也会起 4 个进程，造成争抢
