worker_processes 应设为物理核心数而非逻辑核数，配合worker_cpu_affinity绑定、numa分节点部署及系统级文件数调优，才能实现最佳性能。
worker_processes 不是“开越多越好”，关键在于让每个 worker 稳定运行在独立物理核心上，避免调度干扰和缓存抖动。调优不是孤立改一个参数，而是 CPU 分配、内存亲和、连接能力、系统限制四者协同的结果。
明确物理核心数，禁用逻辑核误配
超线程（HT）对 Nginx 这类 I/O 密集型服务收益极低，反而加剧 L1/L2 缓存争用和 TLB 刷新。务必以物理核心为准，而非逻辑 CPU 总数。
- 查真实物理核数：
nproc或lscpu | grep "Core(s) per socket"，再乘以 socket 数 - 32 物理核 → worker_processes 32；64 逻辑核（含 HT）→ 不设为 64
- 推荐写法：
worker_processes auto;（Nginx 1.9.10+ 支持，能识别 NUMA 并按物理核分配）
强制 CPU 绑定，杜绝进程漂移
只设进程数不绑定，等于没调优。未绑定时，worker 可能在不同核心间频繁迁移，导致热点数据无法驻留本地缓存，SSL 会话缓存、共享内存锁等性能敏感路径延迟上升。
- 通用配置：
worker_cpu_affinity auto;（自动错开超线程对，优先分配物理核） - 精细控制（如 8 核）：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; - 严禁多个 worker 绑定同一物理核——会引发锁竞争，抵消绑定收益
NUMA 架构必须分节点部署
双路或多路服务器中，跨 NUMA 节点访问远端内存会使延迟翻倍以上。不能只看总核数，要按节点均分 worker 并绑定本地 CPU 与内存。
- 先执行
numactl --hardware查拓扑，例如：
Node 0: CPU 0–15，本地内存 64GB
Node 1: CPU 16–31，本地内存 64GB - 设
worker_processes 16（每节点 8 个），再用worker_cpu_affinity分两组绑定 - Nginx 自身不支持内存绑定，需用
numactl启动：numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx -g 'daemon off;'
另一组对应 Node 1，建议通过 systemd override 或启动脚本分片管理
同步提升连接容量与系统资源上限
高 worker 数若搭配低连接数或系统限制，实际并发仍卡在瓶颈处，典型报错：socket() failed (24: Too many open files)。
- 单 worker 连接数建议：2048～32768（静态服务可取高值，注意每个连接约占用 240 字节内存）
- Nginx 主配置加：
worker_rlimit_nofile 100000; - 系统级设置：
→/etc/security/limits.conf中为 nginx 用户设nofile 1000000
→sysctl -w fs.file-max=2097152并写入/etc/sysctl.conf - events 块中启用：
use epoll;、multi_accept on;、accept_mutex off;（高并发下实测有效）
验证是否生效，不能只看 ps 或 taskset。要用 numastat -p PID 检查内存分配占比，理想情况 >95% 的内存访问应落在绑定的 NUMA 节点内。不复杂但容易忽略细节。
