worker_priority通常不生效，因其仅尝试设置nice值，需同时满足root启动、limits.conf授权、worker_rlimit_priority启用及未被systemd覆盖；真正保障算力的是CPU绑核、systemd资源管控（Nice=-5+CPUQuota=80%+CPUAffinity）和干扰抑制。
直接调 worker_priority 很难真正保障算力，它只是尝试设 nice 值，多数生产环境里根本不起作用。真正能稳住 Nginx 算力的，是 CPU 绑核、systemd 资源管控和干扰抑制这三件事。
为什么 worker_priority 通常不生效
你配了 worker_priority -5，但 ps -o pid,ni,comm -C nginx | grep worker 显示 ni 还是 0，原因很实在：
- Nginx 没以 root 启动，或容器里没加
--cap-add=SYS_NICE -
/etc/security/limits.conf没给 nginx 用户配 priority 限制，比如缺了这两行：nginx soft priority 10nginx hard priority 15 - Nginx 配置里漏了 worker_rlimit_priority 10（数值必须 ≥ 你设的 worker_priority）
- systemd 服务里写了
Nice=，它会直接覆盖 Nginx 内部配置
更可靠：用 systemd 统一控 Nice 和 CPU 资源
在 /etc/systemd/system/nginx.service.d/override.conf 里写：
[Service] Nice=-5 CPUQuota=80% CPUAffinity=0-3 CPUSchedulingPolicy=other
这样既提升了调度权重，又锁定了可用 CPU 核心，还保证最低 20% 的算力不被挤占。比在 nginx.conf 里零散调参数稳定得多，也兼容 cgroup v2。
CPU 绑核比调优先级更关键
跨核迁移带来的缓存失效和上下文切换抖动，比 nice 值差几格影响大得多。推荐：
- 物理机或独占虚拟机：用 worker_cpu_affinity auto;（Nginx ≥ 1.12.0）
- 4 核机器手动绑： worker_cpu_affinity 0001 0010 0100 1000;
- NUMA 架构下，还要配合
numactl --cpunodebind=0 --membind=0启动，避免远端内存访问
主动压制干扰源，等于变相提优先级
不是把 Nginx 调多高，而是让其他进程别抢——这才是高负载下延迟稳定的底层逻辑：
- 备份脚本、日志轮转、监控采集全部用
nice 10 ionice -c 3启动 - 同机部署的 MySQL、Redis 也配
CPUQuota=60%，避免互相卡死 - 调低
vm.swappiness=1，减少内存压力触发的内核线程唤醒
