worker_processes设得过多必然导致性能劣化：引发高频上下文切换（cs超5万/s、sy%＞15%）、加剧锁争用（futex_wait_queue_me阻塞）、破坏CPU缓存局部性（cache-misses激增）、加重软中断瓶颈（%si升高、重传增多）。
worker_processes 设置过多会直接引发 CPU 调度层面的实质性问题，核心是打破 Nginx 事件驱动模型与硬件资源的匹配关系，不是“可能影响”，而是必然导致可测量的性能劣化。
上下文切换开销剧增
每个 worker 进程在内核中是一个独立调度实体。当进程数远超可用 CPU 核心数（例如 16 核机器设为 32 个 worker），内核必须频繁在多个就绪态 worker 间切换——每次切换需保存/恢复寄存器、TLB、缓存状态。这会显著抬高系统态 CPU 使用率（sy%），实测中 sy% 可从 2%～3% 升至 15% 以上，有效计算时间被大量吞噬。
- top 或 htop 中观察到 %CPU 总体不高，但 sy 列持续高于 10%，就是典型信号
- vmstat 1 输出中 cs（context switch）值异常升高，常突破 50000+/s
惊群效应未完全消除
尽管 Nginx 1.9.1+ 默认启用 accept_mutex 缓解惊群，但该机制仅作用于新连接接入阶段。在高并发短连接场景下，大量 worker 仍会同时竞争 epoll_wait 返回后的事件分发、共享内存锁（如 limit_conn、stub_status）、日志写入等资源，造成锁争用和线程阻塞。
- ps -eo pid,ppid,comm,wchan | grep nginx 可看到多个 worker 长期停在 futex_wait_queue_me 等锁等待状态
- perf record -e sched:sched_switch -a sleep 10 后分析，能清晰看到进程在锁点频繁进出调度队列
CPU 缓存局部性被破坏
多个 worker 在同一物理核心上轮转执行时，前一个 worker 加载的指令与数据缓存（L1/L2）很快被后一个覆盖。尤其当 worker 处理不同域名、不同 upstream 的请求时，缓存命中率断崖式下降，实际指令执行效率降低 20%～40%。
- 使用 perf stat -e cache-references,cache-misses -p $(pgrep -f "nginx: worker") 观察，cache-misses 比例明显高于 worker 数等于核心数时
- 若未配置 worker_cpu_affinity，/proc/
/status 中的 cpus_allowed_list 显示为全核开放，加剧跨核迁移
软中断处理瓶颈显性化
每个 worker 独立调用 epoll_wait，当网络包洪峰到来时，内核软中断（NET_RX）需将数据分发给多个 worker。worker 过多会导致软中断处理线程（ksoftirqd）长期满载，表现为 %si 持续偏高，且 netstat -s 输出中 packet receive errors 或 tcp timeouts 上升。
- watch -n1 'cat /proc/stat | grep ^soft' 查看软中断计数增速是否异常
- 结合 cat /proc/net/snmp | grep -i "retrans"，确认是否因处理延迟引发重传
