worker_priority不能确保反向代理高负载下获得更高调度优先级，仅当满足root启动、limits.conf配置priority限制、worker_rlimit_priority启用及Linux环境四前提时才可能生效，推荐取值-5至-10并须用ps验证ni值及高负载延迟测试。

worker_priority 不能确保反向代理在高负载下获得更高调度优先级。它只是一个尝试调整 Linux nice 值的配置项，是否生效、是否带来实际收益，取决于四个硬性前提是否全部满足，且在绝大多数生产环境中（尤其是容器化、非 root 启动、默认调度策略）完全无效。

worker_priority 生效的四个必要条件

缺一不可，否则配置等于未写：

• Nginx 必须以 root 用户启动，或容器中显式添加 --cap-add=SYS_NICE（普通用户无法设负值，系统静默忽略）
• /etc/security/limits.conf 中必须为 nginx 用户配置 priority 限制，例如：
  nginx soft priority 10
  nginx hard priority 15
• Nginx 配置中必须显式启用资源限制：worker_rlimit_priority 10（数值需 ≥ 你设置的 worker_priority）
• 运行环境必须是 Linux；Windows/macOS 下该指令被完全忽略，SCHED_FIFO 等实时策略 Nginx 官方明确不推荐

合理取值与风险控制

目标不是“抢光 CPU”，而是让 worker 在争抢中略占优势，同时保障系统基础服务可用：

• 推荐范围：-5 到 -10——实测在物理机独占部署中可使 P95 延迟下降约 10%～12%
• 避免 -15 及更低：systemd 默认 -10，sshd、journald、监控 agent 多在 -5～-10 区间，压得太低会导致运维通道卡顿甚至失联
• 若与 MySQL、Redis 共机，先查其当前 nice 值（ps -o pid,ni,comm -C mysqld），Nginx 设为比其高 3～5 即可（如 MySQL 是 -5，则 Nginx 设 -2 或 0）

必须验证，不能只看 reload 成功

配置后务必逐项确认是否真正落地：

• 执行 nginx -t && systemctl reload nginx
• 立即运行：ps -o pid,ni,comm -C nginx | grep worker——只看 worker 进程，ni 列必须严格等于你设置的值（master 进程 ni 无意义）
• 模拟高负载验证效果：stress-ng --cpu 4 --timeout 30s 拉满 CPU，同时用 curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost/proxy-endpoint 测延迟波动，对比调优前后 P95 变化

更可靠、更直接的替代方案

相比依赖脆弱的 nice 调整，这些方法见效更快、稳定性更高、副作用更小：

• 绑定 CPU 核心：使用 worker_cpu_affinity auto;（Linux 4.0+），让每个 worker 固定运行在独立物理核，消除跨核缓存失效和调度抖动
• 系统级资源约束：在 systemd service 文件中配置 CPUQuota=80% 和 Nice=-5，比 Nginx 内部配置更可控、更易审计
• 优化连接模型：启用 epoll、关闭 accept_mutex、开启 multi_accept on;，提升突发连接吞吐一致性
• 检查系统限制匹配：确保 worker_rlimit_nofile 与 ulimit -n 一致，避免因 “too many open files” 直接丢弃请求