worker_priority仅在四个前提全满足时才生效：root权限或SYS_NICE能力、/etc/security/limits.conf配置priority限制、启用worker_rlimit_priority指令、Linux环境；推荐设为-5至-7，需用ps验证ni值并实测延迟改善。
worker_priority 不能直接“提升调度优先级”，它只是尝试设置 Linux 进程的 nice 值，而该值是否生效、是否影响实际调度，取决于四个硬性前提是否全部满足。多数生产环境（尤其是容器化、systemd 管理、非 root 启动）下，配置了也无效。
worker_priority 生效的四个必要条件
缺一不可：
-
必须以 root 启动 Nginx，或容器中显式添加
--cap-add=SYS_NICE；普通用户无法设负值，系统会静默忽略 -
/etc/security/limits.conf 中必须为 nginx 用户配置 priority 限制，例如：
nginx soft priority 10nginx hard priority 15 -
Nginx 配置中必须启用资源限制指令：
worker_rlimit_priority 10;（数值需 ≥ 你设置的 worker_priority） - 运行环境必须是 Linux；Windows/macOS 下该指令完全被忽略
合理取值与安全边界
目标不是压到最低，而是让 Nginx 在 CPU 争抢中更稳定响应，同时不挤占关键系统进程：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 推荐范围：-5 到 -7；物理机独占部署且观察到 worker 常驻 ni = +5 或更高时可尝试
- 避免 -10 及更低：systemd 默认 -10，内核线程默认 -5，再压低易导致 SSH 登录卡顿、监控失联、健康检查失败
- 若与 MySQL/Redis 共机，先查其当前 nice 值（
ps -o pid,ni,comm -C mysqld），Nginx 设为比它高 3～5 即可（如 MySQL 是 -5，则 Nginx 设 -2 或 0）
必须验证，不能只看 reload 成功
配置后必须分三步确认：
- 执行
ps -o pid,ni,comm -C nginx | grep worker—— 只看 worker 进程，ni 列必须严格等于你设置的值（如配了 -5，就必须看到 -5；master 进程的 ni 无意义） - 在真实负载下测试：用
stress-ng --cpu 4 --timeout 30s拉高 CPU，同时持续请求curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost，对比 P95 延迟波动是否收窄 - 若 ni 仍为 0 或延迟无改善，说明前提未满足，或收益本就微弱
比 worker_priority 更有效、更可控的做法
这些方法不依赖权限和系统策略，落地稳定、效果明确：
-
绑定 CPU 核心：
worker_cpu_affinity auto;减少跨核缓存失效和上下文切换抖动 -
用 systemd 统一管控：在
/etc/systemd/system/nginx.service.d/override.conf中写：[Service]Nice=-5CPUAffinity=0-3CPUQuota=80%—— 比 Nginx 内部配置更可靠，且兼容 cgroup v2 -
调优事件模型：
use epoll;+multi_accept on;+accept_mutex off;，显著提升突发连接吞吐一致性 -
检查并匹配系统限制：
worker_rlimit_nofile必须 ≥ulimit -n，否则出现 “too many open files” 会直接丢请求
