nginx的worker_priority并非直接提升响应优先级，其生效须同时满足四前提：linux系统、root权限或cap_sys_nice、limits.conf配置priority限制、nginx中显式设置worker_rlimit_priority；推荐取值-5至-8，需用ps验证ni值并结合高负载测试延迟变化。
Nginx 的 worker_priority 并不能直接提升高负载下的响应优先级，它只是尝试设置 worker 进程的 nice 值，而该值是否生效、是否影响调度，取决于多个硬性条件是否全部满足。多数生产环境（尤其是容器化、systemd 管理、非 root 启动）下，这个配置实际无效，设了也白设。
必须同时满足的四个前提才可能生效
- 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 下该指令被完全忽略
缺一不可。只要其中一项不满足，ps -o pid,ni,comm -C nginx | grep worker 查到的 ni 值就仍是默认的 0。
推荐取值范围是 -5 到 -8
- 设为 -5 或 -6 是较稳妥的选择，实测在物理机独占部署中可使 P95 延迟下降约 10%～20%
- 不建议低于 -10：systemd、sshd、监控 agent 等关键进程通常运行在 -5～-10 区间，再压低易导致运维通道卡顿甚至失联
- 若与 MySQL、Redis 共机，先查它们的当前 nice 值（如
ps -o pid,ni,comm -C mysqld），Nginx 设为比其高 3～5 即可（例如 MySQL 是 -5，则 Nginx 设为 0 或 -2）
验证是否真正落地
- 重启后执行：
ps -o pid,ni,comm -C nginx | grep worker—— ni 列必须严格等于你设置的值 - 模拟真实压力：用
stress-ng --cpu 4 --timeout 30s拉高 CPU，同时持续请求：curl -o /dev/null -s -w "%{time_starttransfer}\n" http://localhost/test.jpg观察 P95 延迟波动是否收窄；若无变化，说明未生效或收益可忽略
更可靠、更可控的替代方案
-
绑定 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;，显著提升突发连接吞吐 -
限制竞争服务资源：通过 systemd 的
CPUQuota=70%或 cgroups v2 控制其他进程 CPU 使用上限
worker_priority 是个边缘微调项，不是性能加速器。把精力放在绑核、事件模型、资源隔离和系统限制上，效果更确定，风险更低。
