nginx进程管理核心是精准匹配硬件与负载，而非堆高数值：worker_processes应设为物理cpu核心数（推荐auto），worker_connections需与ulimit -n及worker_rlimit_nofile对齐，并在容器中动态适配cgroups限制。
Nginx 进程管理的核心是让 master-worker 架构 与硬件资源、实际负载精准匹配，而不是简单堆高数值。配得准，比配得多更重要。
worker_processes 设置要贴合物理 CPU 核心数
这个参数决定启动多少个独立 worker 进程，每个进程单线程处理连接：
- 优先设为
auto：Nginx 自动读取物理核心数并设置，覆盖绝大多数场景 - 手动指定时，按物理核数来（如 8 核服务器设为 8），不建议用超线程逻辑核数（如 8c16t 仍设 8）
- 避免设为 1（仅限调试或极低流量），也避免远超物理核数（如 32 核机器设 64），否则会加剧上下文切换、降低 CPU 缓存命中率
worker_connections 需与系统限制对齐
单个 worker 能处理的并发连接数，受操作系统文件描述符上限制约：
- 在
events { }块中设置，常见值为 4096、8192 或更高 - 必须同步配置
worker_rlimit_nofile（全局块），且该值需大于worker_connections - 检查系统级限制：
ulimit -n；若不足，需在/etc/security/limits.conf中提升，并确保服务启动时生效
容器环境必须动态适配 cgroups 限制
Docker 或 Kubernetes 环境中，宿主机核数 ≠ 容器可见核数：
- 官方镜像（如
nginx:alpine）自带30-tune-worker-processes.sh，会自动读取 cgroups 的cpu.cfs_quota_us和cpu.cfs_period_us计算可用核数 - 使用
docker run --cpus=2时，确保基础镜像支持该检测；否则可显式传入环境变量（如NGINX_WORKER_PROCESSES=2）覆盖 - 禁止在 Dockerfile 中硬编码
worker_processes 4，否则单核容器也会起 4 个进程，引发争抢
配套调优不可忽略
单独调高进程数或连接数效果有限，需协同优化：
- 启用
worker_cpu_affinity auto，让每个 worker 绑定到独立物理核，减少缓存抖动 - Linux 下固定用
use epoll，配合multi_accept on批量收连接，提升吞吐 - 关闭
accept_mutex off（高并发场景），避免 worker 间锁竞争 - 内存估算要留余量：每个连接约占用 256 字节结构体内存，SSL 和长连接还需额外开销
