Nginx Worker Process 性能优化核心是匹配CPU核心数设worker_processes为auto、调高worker_connections并同步提升系统文件描述符限制、启用worker_cpu_affinity绑定CPU核心、配合epoll与合理超时策略提升连接复用率。
Worker Process 是 Nginx 高性能的核心载体，它不靠多线程，而是靠“一个进程处理数万连接”的异步非阻塞模型。优化它，不是盲目加数量，而是让每个进程真正跑满 CPU、少切换、少等待。
匹配 CPU 核心数，避免上下文开销
worker_processes 设置过高，会导致频繁进程调度和缓存失效；过低则无法压满多核资源。最稳妥的做法是：
- 设为 auto：Nginx 自动读取 CPU 核心数（如 8 核 → 启动 8 个 Worker）
- 避免设为 CPU 核心数的 2 倍或更高：实测中超过核心数后 QPS 不升反降，因上下文切换开销盖过并行收益
- 若服务器混跑其他 CPU 密集型服务，可酌情减配（如 8 核机器设为 6），留出余量
调高单进程连接上限，配合系统限制
每个 Worker 能承载多少连接，取决于 worker_connections 和系统级文件描述符限制（ulimit）。两者必须协同调整：
- 配置示例：
worker_connections 10240;（而非默认 1024） - 同步提升系统上限：
fs.file-max = 100000，并为 nginx 用户设置nofile 100000 - 注意：实际并发连接数 ≈ worker_processes × worker_connections，8 核+10240 → 理论支持约 8 万连接
绑定 CPU 核心，减少跨核缓存抖动
启用 worker_cpu_affinity 可让每个 Worker 固定运行在指定 CPU 核上，提升 L1/L2 缓存命中率：
- 双核示例：
worker_cpu_affinity 01 10; - 8 核自动绑定：
worker_cpu_affinity auto;（Nginx 1.12.0+ 支持） - 效果明显场景：高吞吐静态文件服务、TLS 卸载等 CPU-bound 任务
配合事件模型与超时策略，释放 Worker 资源
Worker 进程的高效，依赖于快速回收空闲连接和避免阻塞等待：
- Linux 必用
use epoll;，比 select/poll 更适合万级并发 -
keepalive_timeout 30;+keepalive_requests 1000;提升连接复用率，减少新建连接压力 - 合理设置
client_header_timeout和proxy_read_timeout，防止慢客户端或后端拖住 Worker
