worker_priority不能直接提升nginx调度优先级，仅尝试设置nice值，生效需同时满足四前提：root权限或cap_sys_nice、limits.conf配置priority限制、nginx中显式设置worker_rlimit_priority、运行于linux；推荐取值-5至-8，须用ps验证ni值并结合高负载测试延迟变化。
worker_priority 不能直接提升 Nginx 在高负载下的调度优先级——它只是尝试设置 Linux 的 nice 值，而该值是否生效、是否带来实际收益，取决于多个硬性前提是否全部满足。多数生产环境（尤其是容器化、非 root 启动、systemd 管理）下，这个配置实际无效，甚至设为负值可能干扰系统稳定性。
它生效的四个必要条件
缺一不可，否则配置被内核静默忽略：
- 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 下完全不识别该指令
合理取值与风险控制
目标不是“抢光 CPU”，而是让 worker 在争抢中略占优势，同时保障 SSH、数据库、监控等关键进程可用：
- 推荐范围：-5 到 -8；实测通常可使 P95 延迟下降 10%～20%
- 避免 -10 及更低：systemd 默认为 -10，内核线程为 -5，再压低易导致运维通道卡顿或健康检查失败
- 若与 MySQL/Redis 共机，先查其当前 nice 值（ps -o pid,ni,comm -C mysqld），Nginx 设为比其高 3～5 即可（如 MySQL 是 -5，则 Nginx 设 -2 或 0）
必须验证，否则等于没配
reload 成功 ≠ 优先级已应用。三步确认：
- 重启后立即执行：ps -o pid,ni,comm -C nginx | grep worker —— ni 列必须严格等于你配置的值（注意：master 进程的 ni 无意义）
- 模拟高负载：用 stress-ng --cpu 4 --timeout 30s 拉高 CPU，同时持续请求静态资源
- 对比延迟波动：用 curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost/xxx.jpg 测 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 内部配置更稳定、可审计、支持 cgroup v2 - 优化连接模型：multi_accept on; + accept_mutex off; + use epoll;，显著提升突发连接吞吐一致性
- 限制其他服务资源：用 CPUQuota=70% 或 cgroups v2 限制数据库、日志服务等 CPU 配额，从源头减少抖动
