worker_priority在系统资源紧张时无法单独保障网关响应，必须同时满足root权限或cap_sys_nice、limits.conf配置priority限制、nginx中显式设置worker_rlimit_priority、运行于linux四大前提，推荐取值-5至-10并需ps验证ni值及高负载测试延迟变化。

在系统资源极端紧张时，worker_priority 本身无法“优先保障”网关进程的调度权限——它只是一个对 Linux nice 值的间接建议，且在绝大多数真实生产环境中（尤其是容器化、非 root、默认调度策略下）根本不起作用。真正能起效的，是明确授权、绑定资源、限制干扰这一整套动作。

必须满足的四个生效前提

缺一不可，否则配置形同虚设：

• 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 或 cgroup v2 默认覆盖场景下，该指令被完全忽略

取值要克制，不是越低越好

目标是在 CPU 抢占中略占优势，而非压垮系统基础服务：

• 推荐范围：-5 到 -10 —— 在多数网关场景下可降低 P95 延迟约 10%～20%
• 避免 -15 及更低：systemd、sshd、journald 等关键进程通常在 -5～-10 区间，再压低易导致 SSH 卡顿、监控失联、日志堆积
• 混合部署（如 Nginx + MySQL 同机）时，先用 ps -o pid,ni,comm -C nginx 查当前值，仅比默认 0 低 3～5 即可观察效果

验证是否真生效，不能只看 reload 成功

三步确认缺一不可：

• 重启 Nginx：nginx -t && systemctl reload nginx
• 查实际 nice 值：ps -o pid,ni,comm -C nginx | grep worker —— 输出中的 ni 列必须等于你设置的 worker_priority 值（master 进程不参与调度，勿看）
• 模拟极端负载测试：stress-ng --cpu 8 --timeout 60s 拉满 CPU，同时用 curl -I http://localhost 测延迟波动，对比调优前后 P95 变化

更可靠、更适合极端场景的替代方案

比起依赖脆弱的 nice 调整，这些方法稳定性高、副作用小、落地性强：

• CPU 绑核：worker_cpu_affinity auto;（Linux 4.0+），每个 worker 独占一个物理核，大幅减少上下文切换和缓存抖动
• systemd 底层管控：在 /etc/systemd/system/nginx.service.d/override.conf 中写：
  Nice=-5
CPUSchedulingPolicy=other
  比 Nginx 内部配置更稳定、不易被覆盖
• cgroups 资源划界：通过 CPUQuota=70% 或 cpu.weight 保障最小算力供给，防止被突发任务打穿
• 连接模型优化：multi_accept on; + accept_mutex off; + use epoll;，提升短连接吞吐能力，缓解调度压力