worker_processes 应设为物理核心数，配合 worker_cpu_affinity auto 实现绑定，避免超线程干扰；需同步配置 rlimit、epoll、sendfile 等减少上下文切换，最后用 ps 和 vmstat 验证效果。
worker_processes 设置直接影响 Nginx 的上下文切换开销——设得过小，单核压满、请求排队；设得过大，进程频繁争抢 CPU 时间片，调度器反复切换上下文，反而拖慢整体响应。真正有效的配置不是填数字，而是让每个 worker 稳定运行在专属物理核心上，从根源抑制迁移带来的缓存失效和 TLB 刷新。
按物理核心数设置 worker_processes
推荐直接使用 worker_processes auto;（Nginx 1.3.8+ 支持）。它会自动识别服务器的物理 CPU 核心数（不计入超线程逻辑核），避免人为误判。例如 8 物理核服务器，auto 就启动 8 个 worker；若手动写成 16，就可能因跨核调度引发额外开销。
- 设为 1：所有连接挤在一个进程里，无法并行，高并发时上下文切换集中在单核，CPU 利用率爆表但吞吐上不去
- 设为远超物理核数（如 32 核配 64 worker）：进程调度竞争加剧，
vmstat中 cs（context switch）值飙升，常突破 20 万/秒 - 容器或云环境注意：
nproc输出为准，/proc/cpuinfo可能虚报，尤其受 CPU limit 限制时
必须配合 worker_cpu_affinity 实现稳定绑定
只设 worker_processes 不够，关键是要让每个 worker 长期驻留在固定物理核上。启用 worker_cpu_affinity auto;（Nginx 1.9.10+）是最稳妥的方式——它自动跳过超线程对称核，按物理核顺序一对一绑定，规避 NUMA 错配风险。
- 禁用
worker_priority或外部sched_setaffinity脚本，防止干扰 Nginx 自身调度逻辑 - 验证是否生效：运行
ps -eo pid,args,psr | grep 'nginx: worker'，各 worker 的 PSR 列应显示不同且稳定的 CPU 编号（如 0、1、2、3） - 若看到某 worker 的 PSR 值频繁跳变，说明绑定失败，大概率是资源不足或 affinity 配置冲突
资源供给要跟上，否则绑定形同虚设
CPU 绑定只是前提，worker 若因文件描述符耗尽或被内核抢占，照样会被迁走。必须同步保障基础资源：
-
worker_rlimit_nofile 65535;—— 显式声明单进程最大文件描述符，该值需 ≥worker_connections × worker_processes -
/etc/security/limits.conf中为 nginx 用户设soft nofile 65535和hard nofile 65535 -
use epoll;+multi_accept on;—— 提升事件分发效率，减少无效唤醒导致的隐式切换
优化 I/O 路径，减少隐式上下文切换
静态文件服务是上下文切换大户。传统 read()+write() 模式涉及用户态与内核态四次切换；而启用零拷贝路径可压缩至两次：
-
sendfile on;—— 数据从磁盘到网卡全程在内核态搬运，绕过用户空间 -
tcp_nopush on;与tcp_nodelay on;配合使用，避免小包堆积或延迟发送，降低网络层抖动引发的调度压力 - 关闭未启用模块（如 Lua、Perl），减小 worker 内存 footprint，提升 L3 缓存命中率，间接抑制因 cache miss 导致的指令周期浪费
不复杂但容易忽略：上下文切换高，往往不是连接太多，而是进程没绑牢、资源没给够、I/O 走了低效路径。调完参数，一定要用 ps、taskset、vmstat 实测验证，而不是只看 reload 成功。
