worker_priority 配置仅在满足四个硬性条件时生效：Nginx需root启动或具备SYS_NICE权限、limits.conf配置priority限制、nginx.conf启用worker_rlimit_priority且值≥worker_priority、运行于Linux且未被systemd Nice=覆盖；否则ni值恒为0。
worker_priority 不能直接“优化 Nginx 进程优先级”，它只是尝试设置 Linux 的 nice 值，是否生效完全取决于系统环境是否满足四个硬性条件。多数生产场景（容器化、systemd 管理、非 root 启动）下该配置实际无效，设了也白设。
必须同时满足的四个前提条件
否则 ps -o pid,ni,comm -C nginx | grep worker 查到的 ni 值永远是 0：
- Nginx 必须以 root 用户启动，或在容器中显式添加
--cap-add=SYS_NICE -
/etc/security/limits.conf中为nginx用户配置priority限制，例如：nginx soft priority 10 nginx hard priority 15
-
nginx.conf全局块中必须启用资源限制：worker_rlimit_priority 10（数值需 ≥worker_priority） - 运行环境必须是 Linux；Windows/macOS 下该指令被忽略，systemd 管理时还可能被
Nice=覆盖
合理取值与风险控制
目标不是压垮其他进程，而是让 worker 在 CPU 竞争中略占优势，同时保障 SSH、监控、数据库等基础服务可用：
- 推荐范围：-5 到 -10
- 物理机或裸金属独占部署下，实测可使 P95 延迟下降约 10%～20%
- 避免低于 -10
- 内核线程默认
-5，systemd 服务常见-10，再压低易导致 SSH 卡顿、MySQL 心跳超时、监控失联
- 内核线程默认
- 混合部署（如共机 MySQL）时：
- 先查 MySQL 当前 nice 值：
ps -o pid,ni,comm -C mysqld - 将 Nginx 设为比它高 3～5（例如 MySQL 是
-5，Nginx 设-2或0）
- 先查 MySQL 当前 nice 值：
必须验证，不能只看 reload 成功
三步确认是否真正落地：
- 执行
nginx -t && systemctl reload nginx - 立即运行
ps -o pid,ni,comm -C nginx | grep worker—— 只看 worker 进程，ni列必须严格等于你配置的值（如配-5，就必须看到-5） - 模拟真实高负载：
stress-ng --cpu 4 --timeout 30s拉满 CPU，同时用curl -o /dev/null -s -w "%{time_total}\n" http://localhost测延迟波动，重点关注 P95 变化
更可靠、更推荐的替代方案
与其调试一个易失效的参数，不如做这些真正可控的事：
- 使用
worker_cpu_affinity auto：每个 worker 绑定独立物理核，减少跨核缓存失效和上下文切换 - 通过 systemd 统一管控：在
/etc/systemd/system/nginx.service.d/override.conf中写入[Service] Nice=-5 CPUSchedulingPolicy=other
然后执行
systemctl daemon-reload && systemctl restart nginx - 关闭 accept 锁：
accept_mutex off;（配合多 worker 时降低锁竞争）
不复杂但容易忽略。
