应优先监控上下文切换数（cs）和cpu分布是否异常：cs＞30000持续10秒且qps下降，大概率是worker_processes过多引发调度风暴；cpu负载不均或worker进程频繁跨核跳转，说明worker_cpu_affinity未生效；worker_processes×worker_connections超ulimit-n的70%、单worker内存超200mb持续增长、%wa高且r/s不涨，均会加剧调度压力；临时验证可将worker_processes设为1或2并reload，若cs断崖下降＞60%，即可确认问题。
直接看上下文切换数和 CPU 分布是否异常，而不是只盯着配置值本身。worker_processes 过高会迫使内核频繁调度大量 worker 进程，尤其当它们没绑定核心或争抢资源时，调度开销会迅速放大。
查上下文切换率是否超标
用 vmstat 1 持续观察，重点关注 cs（context switch）列：
- 每秒 cs
- 5000 ≤ cs
- cs > 30000 且持续超过 10 秒，同时 QPS 不升反降 → 高概率是 worker_processes 过多引发的调度风暴
再配合 perf stat -e sched:sched_switch -p $(pgrep nginx | head -1)，确认调度事件是否集中在 worker 进程间高频跳转。
看 CPU 核心负载是否严重不均
运行 htop 或 top -H，按 P 排序 CPU 使用率，观察：
- 多个 worker 进程集中在同一颗 CPU 上跑满（比如 CPU0 占用 95%，其余核心低于 20%）→ 说明没配
worker_cpu_affinity，或配错了 - 各 worker 的 PSR（所在 CPU 编号）频繁跳变（如某进程一会儿在 CPU2，一会儿跑到 CPU5）→ 亲和性未生效，或被外部工具干扰
- 用 ps -eo pid,args,psr | grep 'nginx: worker' 可固定抓取当前绑定状态
验进程数是否远超物理承载能力
不要只比对逻辑核数。重点检查三项是否失衡：
-
worker_processes × worker_connections 是否明显超过
ulimit -n的 70%？超限会导致连接退化、缓冲区反复分配，加剧调度压力 - 每个 worker 内存占用是否稳定？用 ps aux --sort=-%mem | grep nginx 看 RES 值。若单个 worker 超过 200MB 且随时间上涨 → 可能有模块泄漏（如 Lua），间接拖慢响应、延长调度周期
- 磁盘 IO 是否拖后腿？iostat -x 1 中 %wa 高 + avgqu-sz 大 + r/s 不涨 → 说明 worker 在等 IO，空转排队，白白增加切换次数
快速验证与临时止血
不改其他参数，只做两件事：
- 把
worker_processes改成 1 或 2，执行 nginx -s reload - 10 秒后再跑一次 vmstat 1，看 cs 是否断崖下降（通常降幅 >60%）
如果下降显著，基本锁定是进程数过高所致。后续再按 CPU 类型（纯计算 / 静态文件 / 反向代理）和 IO 能力逐步调优，而不是盲目追求数值匹配逻辑核数。
