worker_priority生效需满足四前提：Linux系统、root权限或CAP_SYS_NICE、limits.conf配置priority限制、Nginx中显式设置worker_rlimit_priority；推荐取值-5至-10，须用ps验证ni值并结合高负载测试延迟变化。
worker_priority 不是“设了就生效”的开关，它在高负载下保障 Nginx 响应性的作用，高度依赖权限、调度策略和系统环境。
worker_priority 生效的四个硬性前提
配置 worker_priority -5 后发现 ps -o pid,ni,comm -C nginx 显示的 ni 仍是 0？大概率是以下任一条件未满足：
- 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 下该指令被完全忽略
为什么设了 -10 却不如 -5 稳定
内核进程默认 ni = -5，systemd 服务常见为 -10。盲目压到 -15 或 -20 会直接挤压 SSH、监控采集、数据库心跳等关键进程：
- 实测中，
stress-ng --cpu 8拉满 CPU 后，worker_priority -10可使 P95 延迟下降约 12%，而-15下 SSH 登录延迟飙升至 3s+，部分健康检查失败 - 混合部署场景（如 Nginx + MySQL 共机），建议先用
ps -o pid,ni,comm -C mysqld查 MySQL 当前 nice 值，Nginx 设为比其高 3～5 即可（例如 MySQL 是 -5，则 Nginx 设 -2 或 0） - 默认调度策略是
SCHED_OTHER，此时worker_priority仅影响时间片权重，不改变抢占行为；切SCHED_FIFO等实时策略是危险操作，Nginx 官方明确不推荐
验证是否真正生效的三步法
reload 成功 ≠ 优先级已应用。必须逐项确认：
- 执行
nginx -t && systemctl reload nginx后，立即运行ps -o pid,ni,comm -C nginx | grep worker—— 注意只看worker进程，master 进程的ni值无意义 - 输出中的
ni列必须严格等于你配置的worker_priority值（例如配了 -5，就必须看到 -5；若仍为 0，说明前提条件缺失） - 在真实高负载下验证效果：用
curl -o /dev/null -s -w "%{time_total}\n" http://localhost配合stress-ng --cpu 4 --timeout 30s，对比调优前后 P95 延迟波动幅度
更可靠、更可控的替代方案
相比依赖脆弱的 nice 调整，这些方法在生产环境中稳定性更高：
- 用
worker_cpu_affinity auto将每个 worker 绑定到独立 CPU 核心，减少上下文切换开销（尤其在 NUMA 架构上收益明显） - 通过 systemd 服务文件统一控制：
Nice=-5+CPUSchedulingPolicy=other，比 Nginx 内部配置更底层、更稳定 - 容器化部署时，应放弃
worker_priority，改用 cgroup v2 的cpu.weight或cpu.max进行资源配额控制
真正有效的调优是“精准授权 + 合理取值 + 明确验证”。很多线上事故源于把 worker_priority 当成万能开关，却忽略了它背后那一整套操作系统级的依赖链。
