worker_priority仅在root启动、配置worker_rlimit_priority（或授予权限）、且非SCHED_OTHER调度策略下才可能生效；多数容器化或默认环境下实际无效，盲目设为负值反而有害。
在高负载环境下，worker_priority 并不能直接“确保” Nginx 进程获得更高调度优先级——它只是尝试调整 nice 值，且生效条件非常严格。多数生产环境（尤其是容器化、非 root 启动、默认调度策略）下该配置实际无效。盲目设为 -10 或 -20 不仅无益，还可能干扰系统关键进程。
它到底起不起作用？看这三点
worker_priority 是否生效，取决于三个硬性前提同时满足：
- 必须以 root 权限启动 Nginx：普通用户无法调低 nice 值（即设为负数），系统会静默忽略；
-
操作系统需允许提升优先级：需提前配置
worker_rlimit_priority，或通过cap_sys_nice能力授权（如容器中用--cap-add=SYS_NICE）； -
内核调度策略必须支持 nice 调整：默认
SCHED_OTHER下，nice 值仅影响 CPU 时间片权重，不改变抢占行为；若强行切换到SCHED_FIFO等实时策略，反而易导致系统不稳定，Nginx 官方明确不推荐。
什么时候可以谨慎尝试？
仅在以下特定场景下，-5 到 -10 的取值有一定参考价值：
- 物理机部署、CentOS/RHEL 等传统 Linux 环境；
- Nginx 是唯一高负载服务，且与数据库、缓存等关键进程存在明显 CPU 竞争；
- 已通过
top或ps -eo pid,ni,comm观察到 worker 进程常驻低 nice 值（如 +10 以上），说明被系统自动降权； - 配合
worker_cpu_affinity auto和worker_processes auto使用，避免因调度抖动放大延迟。
比 worker_priority 更可靠的做法
与其纠结一个易失效的参数，不如聚焦真正可控的优化路径：
-
绑定 CPU 核心：用
worker_cpu_affinity auto减少跨核缓存失效，效果远超调优 nice 值； -
限制资源竞争：通过 cgroups（如 systemd 的
CPUQuota）或容器平台限制其他服务 CPU 配额，从源头保障 Nginx 资源供给； -
调优连接模型：关闭
accept_mutex、开启multi_accept、使用epoll，显著提升单位时间连接处理能力； -
检查系统限制：确认
worker_rlimit_nofile与系统ulimit -n匹配，避免“too many open files”导致请求被丢弃。
worker_priority 是个有前提的“微调项”，不是高并发的“加速器”。它只在少数裸金属+root+精细管控的组合下才可能产生可测收益。大多数情况下，把精力放在事件模型、连接复用、系统限制和资源隔离上，回报更确定、风险更低。
