worker_priority不能直接优化cpu调度优先级，仅尝试设置nice值，生效须同时满足四个前提：root或sys_nice权限、limits.conf配置priority限制、nginx.conf中启用worker_rlimit_priority且值≥worker_priority、运行于linux；推荐取值-5至-10，需用ps验证ni值并实测p95延迟改善。

worker_priority 不能直接“优化 CPU 调度优先级”，它只是尝试为 Nginx worker 进程设置 Linux 的 nice 值，而该值是否生效、是否影响实际调度，取决于四个硬性前提是否全部满足。多数生产环境（尤其是容器化、systemd 管理、非 root 启动）下，这个配置设了也无效。

worker_priority 生效的四个必要条件

缺一不可，否则 ps 查到的 ni 值永远是 0：

• Nginx 必须以 root 用户启动，或容器中显式添加 --cap-add=SYS_NICE（普通用户无法设负 nice 值，系统静默忽略）
• /etc/security/limits.conf 中必须为 nginx 用户配置 priority 限制，例如：
  nginx soft priority 10
  nginx hard priority 15
• nginx.conf 中必须启用资源限制：worker_rlimit_priority 10（数值需 ≥ 你设置的 worker_priority；仅写 worker_priority 而不配此项，完全无效）
• 运行环境必须是 Linux；Windows/macOS 下该指令被忽略，systemd 管理时还可能被 Nice= 配置覆盖

合理取值与风险控制

目标不是压垮其他进程，而是让 worker 在 CPU 竞争中更稳地响应请求：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 推荐范围：-5 到 -10——在物理机或裸金属独占部署中可测得 P95 延迟下降约 10%～12%
• 避免 -15 及更低：内核线程默认 -5，systemd 服务常见 -10，再压低易导致 SSH 登录卡顿、监控失联、MySQL 心跳超时
• 混合部署时（如 Nginx + MySQL 共机），先用 ps -o pid,ni,comm -C mysqld 查 MySQL 当前 nice 值，Nginx 设为比它高 3～5 即可（例如 MySQL 是 -5，Nginx 设 -2 或 0）

必须验证，不能只看 reload 成功

三步确认是否真起作用：

• 执行 nginx -t && systemctl reload nginx
• 立即运行 ps -o pid,ni,comm -C nginx | grep worker——只看 worker 进程，ni 列必须严格等于你配置的值（比如配了 -5，就必须看到 -5；master 进程的 ni 值无意义）
• 用 stress-ng --cpu 4 --timeout 30s 拉满 CPU，同时用 curl 测延迟波动（关注 P95），对比调优前后变化

比 worker_priority 更可靠的做法

与其花时间调试一个易失效的参数，不如做这些真正可控的事：

• 用 worker_cpu_affinity auto 绑定 CPU 核心，减少跨核缓存失效和上下文切换抖动
• 通过 systemd service 文件统一控制：
  [Service]
  Nice=-5
  CPUSchedulingPolicy=other
  CPUAffinity=0-3
• 启用高效连接模型：multi_accept on; 和 accept_mutex off;，配合 epoll 提升突发吞吐一致性
• 用 cgroups v2 限制其他服务 CPU 使用率，为 Nginx 预留资源带宽，比争抢优先级更可控