worker_priority在绝大多数高负载Nginx场景下不生效，因其依赖root权限、CAP_SYS_NICE能力、limits.conf配置及非SCHED_OTHER策略等严苛前提，且与worker_cpu_affinity机制冲突；真正影响性能的是worker_processes、CPU亲和性及后端阻塞等问题。
worker_priority 在绝大多数高负载 Nginx 场景下不生效，强行设为 -20 反而可能拖垮整个系统。 它不是“抢 CPU 的开关”，而是一个依赖严苛前提的 nice 值声明，且默认调度策略（SCHED_OTHER）下会被内核忽略。
为什么 worker_priority 经常没反应
你改了 worker_priority -10，ps -o pid,ni,comm -C nginx 却显示还是 0——这不是配置写错了，而是条件没满足：
- Nginx 必须以
root启动，或提前授予CAP_SYS_NICEcapability（容器里基本做不到） - 系统必须允许提升 nice 值：要么在
/etc/security/limits.conf中为 nginx 用户配好soft priority和hard priority，要么在 Nginx 配置中启用worker_rlimit_priority - 即使以上都满足，Nginx 默认仍用
SCHED_OTHER调度策略，此时worker_priority仅影响setpriority()系统调用结果，不改变调度行为；要真正“抢占”，得切到SCHED_FIFO或SCHED_RR，但 Nginx 不支持也不推荐 - systemd 管理的实例中，
worker_priority会被覆盖，应改用 service 文件里的Nice=或SystemMaxPriority=
worker_priority 和 worker_cpu_affinity 别混用
两者目标相似（减少争抢），但机制冲突：
-
worker_cpu_affinity是把每个 worker 绑定到独占 CPU 核，靠物理隔离避免调度竞争 -
worker_priority是让多个 worker 在同一组 CPU 上“比谁更急”，反而加剧调度器负担 - 如果你已用
worker_cpu_affinity 1000 0100 0010 0001绑定了 4 个核，再设worker_priority -5没实际意义——进程已经不抢核了，优先级高低不影响执行时长 - 真实高负载网关（如 API 网关）更应优先确保
worker_cpu_affinity+worker_processes auto，而非调worker_priority
真要调优先级，优先走 systemd 或 limits.conf
在现代 Linux 发行版中，worker_priority 是过时路径。更可靠、可审计的方式是：
- 用 systemd：编辑
/etc/systemd/system/nginx.service，加一行Nice=-5，然后systemctl daemon-reload && systemctl restart nginx - 用 limits.conf：对 nginx 用户添加限制，例如
nginx soft priority 5和nginx hard priority 10，再确保 Nginx 启动前 ulimit 生效 - 验证是否落地：不要只看 Nginx 配置，运行
cat /proc/$(pgrep nginx | head -n1)/status | grep Nice，或ps -o pid,ni,comm -C nginx - 注意副作用：设太低（如 -15）会导致 SSH、systemd-journald、数据库等关键进程响应变慢，尤其在突发流量下容易连锁超时
真正决定高负载下 CPU 抢占效率的，是 worker_processes 是否匹配 CPU 核数、worker_cpu_affinity 是否启用、以及后端服务是否阻塞（比如同步调用慢 DB）。worker_priority 是个边缘参数，调它之前，先确认你的 worker_connections 没被撑爆、open_file_cache 没频繁失效、日志没开 debug 级别——这些才是 CPU 占用飙升的常见根因。
