worker_priority需满足四前提才生效：root启动或cap_sys_nice、limits.conf配置priority、启用worker_rlimit_priority、linux环境；推荐值-5至-8，须ps验证ni值并压测延迟。
worker_priority 不是“开箱即用”的加速开关，它只是尝试设置 Linux 进程的 nice 值，能否生效、是否带来收益，完全取决于运行环境是否满足硬性条件。多数生产场景（尤其是容器化、systemd 管理、非 root 启动）下，这个配置实际无效。
必须同时满足的四个前提
缺一不可，否则 ps 查到的 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 下该指令被完全忽略
合理取值与风险控制
目标不是压垮其他进程，而是让 worker 在 CPU 竞争中略占优势，同时保障系统基础服务可用：
- 推荐范围：-5 到 -8——物理机独占部署实测可使 P95 延迟下降约 10%～20%
- 避免低于 -10：systemd、sshd、监控 agent 等关键进程常在 -5～-10 区间，再压低易导致运维失联
- 混合部署时（如共机 MySQL），先查其当前 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 列必须严格等于你配置的值
- 模拟真实压力：stress-ng --cpu 4 --timeout 30s 拉高 CPU，同时用 curl 测延迟波动（关注 P95），对比调优前后变化
更可靠、更直接的替代方案
相比依赖脆弱的 nice 调整，这些方法见效更快、稳定性更高：
- 绑定 CPU 核心：worker_cpu_affinity auto;（Linux 4.0+），每个 worker 独占物理核，消除跨核缓存失效
- 系统级统一管控：在 /etc/systemd/system/nginx.service.d/override.conf 中写入：
[Service]
Nice=-5
CPUSchedulingPolicy=other
然后 systemctl daemon-reload && systemctl restart nginx - 优化连接模型：multi_accept on; + accept_mutex off; + use epoll;，显著提升突发连接吞吐
