Nginx多进程最佳性能关键在于worker_processes、CPU资源、系统限制与业务负载四者对齐；需设worker_processes为物理核心数，启用worker_cpu_affinity绑定核心，并闭环验证worker_connections与系统文件描述符限制。
要让 Nginx 多进程架构发挥最佳性能，关键不是堆进程数，而是让 worker_processes、CPU 资源、系统限制和业务负载四者对齐。配得准，比配得多更重要。
worker_processes 设置：匹配物理核心，避免超线程干扰
这个参数决定启动多少个独立 Worker 进程来处理请求，它直接绑定 CPU 物理资源：
- 首选 auto：Nginx 自动读取当前环境的物理 CPU 核心数，适用于物理机、虚拟机和大多数容器场景
- 手动指定时，按物理核数设（如 8 核服务器设为 8），不要按逻辑核数（如 8c16t 不设 16）——超线程对 Nginx 收益有限，反而增加上下文切换开销
- 禁用
worker_processes 1（除非调试或极低负载），也避免设为远高于物理核数（如 32 核设 64），会导致缓存行失效和锁竞争加剧
worker_cpu_affinity：绑定核心，减少迁移损耗
每个 Worker 进程固定运行在指定 CPU 核心上，可显著提升 L1/L2 缓存命中率和指令流水线效率：
- 配合
worker_processes 4，写成worker_cpu_affinity 0001 0010 0100 1000，即每个进程独占一个核心 - 在 8 核机器上可用
worker_cpu_affinity 00000001 00000010 ...逐位映射，也可用简写形式worker_cpu_affinity auto（1.12.0+ 支持） - 若未配置，Linux 调度器可能频繁迁移进程，导致 TLB 刷新、缓存失效，实测延迟波动上升 15%~30%
连接与系统资源协同：worker_connections 必须闭环验证
单个 Worker 能处理多少连接，不只看配置值，更取决于操作系统级文件描述符上限：
- 在
events { }块中设worker_connections 8192或16384，同时确保worker_rlimit_nofile（全局块）不低于该值 - Linux 下执行
ulimit -n查看当前限制；若不足，需在/etc/security/limits.conf中为 nginx 用户设置：nginx soft nofile 65536nginx hard nofile 65536 - 重启 nginx 前，确认 systemd service 文件中是否含
LimitNOFILE=65536（否则 limits.conf 可能被忽略）
容器环境适配：别让宿主机核数误导你
Docker 或 Kubernetes 环境中，worker_processes auto 默认读的是宿主机核数，而非容器实际配额：
- 官方镜像（如
nginx:alpine）自带30-tune-worker-processes.sh入口脚本，会从/sys/fs/cgroup/cpu.max或/proc/cpuinfo动态推算可用核数 - 使用
docker run --cpus=2时，确保基础镜像支持 cgroups v2 检测；否则建议显式传入环境变量NGINX_WORKER_PROCESSES=2并在配置中引用 - 绝对避免在 Dockerfile 中硬编码
worker_processes 4——单核容器里起 4 个进程只会争抢，降低吞吐
