worker_priority生效需同时满足四前提：root权限或CAP_SYS_NICE、limits.conf配置priority限制、Nginx中显式设置worker_rlimit_priority、运行于Linux；推荐取值-5至-10，须用ps验证ni值并结合高负载测试延迟变化。
要让 worker_priority 在系统资源紧张时真正起作用，关键不是“设个负数”，而是确保它能落地生效——多数线上环境里这个配置根本没生效，还误以为加了就稳了。
必须满足的四个硬性条件
缺一不可，否则配置等于白写：
- Nginx 必须以 root 用户启动，或容器中显式添加
--cap-add=SYS_NICE -
/etc/security/limits.conf 中为 nginx 用户配好 priority 限制，例如：
nginx soft priority 10nginx hard priority 15 - Nginx 配置中必须显式启用资源限制：
worker_rlimit_priority 10;（值需 ≥worker_priority设置） - 运行环境是 Linux；Windows/macOS 下该指令完全被忽略
取值要克制，-5 到 -10 是安全区间
目标不是压垮其他进程，而是让 Nginx worker 在 CPU 抢占中略占优势：
- 默认 nice 值是 0，设为 -5 或 -8 足够提升响应及时性，P95 延迟通常可降 10%～20%
- 避免设到 -15 及更低：systemd、sshd、数据库等关键服务常在 -5～-10 区间，再往下容易导致 SSH 卡顿、监控失联
- 混合部署（如 Nginx + MySQL 同机）时，先用
ps -o pid,ni,comm -C nginx查当前值，只比默认低 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=-5CPUSchedulingPolicy=other
比 Nginx 内部配置更底层、更稳定 - 搭配
multi_accept on;和accept_mutex off;，让所有 worker 同时抢连接，适合高并发短连接场景
