worker_priority仅在Linux下以root启动且满足权限与配置前提时，为worker进程设置nice值；它不影响master进程，推荐值为-5至-7，需用ps验证ni值并实测延迟。
worker_priority 不作用于 Master 进程，也不直接调整 Master 派生的子进程（即 worker 进程）的系统优先级——它只在满足全部前提时，尝试为 worker 进程 设置 Linux 的 nice 值。Master 进程的 ni 值始终不受该指令影响，且其调度行为与 worker 无关。
真正起作用的对象是 worker 进程
nginx 启动后，master 进程负责管理，实际处理请求的是由它 fork 出来的 worker 进程。worker_priority 的目标就是让这些 worker 在 CPU 竞争中更早被调度，但前提是：
- nginx 必须以 root 启动，或容器中添加
--cap-add=SYS_NICE - /etc/security/limits.conf 中为 nginx 用户配置：
nginx soft priority 10nginx hard priority 15 - nginx.conf 中必须启用：
worker_rlimit_priority 10（数值 ≥ 你设的 worker_priority） - 运行环境为 Linux；systemd 管理时还可能被
Nice=覆盖
配置写法与典型值
在 nginx.conf 的全局块（main context）中添加：
worker_priority -5;
worker_rlimit_priority 10;
推荐取值范围为 -5 到 -7。设为 -10 或更低容易导致 ssh、监控 agent、数据库等关键进程响应变慢，尤其在混合部署场景下。
验证是否真正生效
reload 配置后，不能只看是否成功，必须实测：
- 执行：
ps -o pid,ni,comm -C nginx | grep worker
输出中 ni 列必须严格等于你配置的值（如 -5），master 进程的 ni 值无意义 - 用
stress-ng --cpu 4 --timeout 30s制造高负载，同时用curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost测延迟波动，观察 P95 是否收窄
比 worker_priority 更稳定的做法
多数生产环境（尤其是容器、systemd、共享主机）下，worker_priority 很难生效。更可靠的方式是：
- 用
worker_cpu_affinity auto;绑定 worker 到不同 CPU 核心，减少上下文切换开销 - 通过 systemd service 文件统一控制：
Nice=-5+CPUSchedulingPolicy=other - 启用
use epoll;和listen 80 reuseport;提升连接分发效率 - 对非关键服务做 CPU 限流，例如 systemd 中设置
CPUQuota=70%
