worker_priority不能直接调整nginx工作进程系统级权重，仅尝试设置nice值，生效须同时满足四前提：root启动或cap_sys_nice、limits.conf配置priority限制、nginx.conf中启用worker_rlimit_priority、运行于linux；推荐-5至-10，需ps验证ni值并高负载测延迟。
worker_priority 不能直接“调整工作进程系统级权重”，它只是尝试为 Nginx worker 进程设置 Linux 的 nice 值，而该值是否生效、是否影响实际调度权重，取决于四个硬性前提是否全部满足。多数场景下（容器、systemd 管理、非 root 启动），配置后 ni 值仍为 0，等于未生效。
生效必须同时满足的四个条件
缺一不可，否则 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 配置中必须启用资源限制：worker_rlimit_priority 10（仅写 worker_priority 而不配此项，完全无效）
- 运行环境必须是 Linux；Windows/macOS 下该指令被忽略，systemd 管理时还可能被 Nice= 配置覆盖
取值要讲逻辑，不是越低越好
目标不是压垮其他进程，而是让 worker 在 CPU 竞争中更稳地响应请求：
- 推荐范围：-5 到 -10——在物理机、裸金属、单一服务场景下有可测收益
- 避免 -15 及更低：内核线程默认 -5，systemd 服务常见 -10，再压低会导致 SSH 登录卡顿、监控失联、MySQL 心跳超时
- 混合部署时（如 Nginx + MySQL 共机），先查 MySQL 当前 nice 值：
ps -o pid,ni,comm -C mysqld，Nginx 设为比它高 3～5 即可（例如 MySQL 是 -5，Nginx 设 -2 或 0）
必须验证，不能只看 reload 成功
三步确认是否真起作用：
- 执行 nginx -t && systemctl reload nginx
- 立即运行 ps -o pid,ni,comm -C nginx | grep worker——只看 worker 进程，master 的 ni 值无意义；输出 ni 列必须严格等于你配置的值
- 用 stress-ng --cpu 4 --timeout 30s 拉满 CPU，同时用 curl 测延迟波动（关注 P95），对比调优前后变化
比 worker_priority 更可靠的做法
与其花时间调试一个易失效的参数，不如做这些真正可控的事：
- 用 worker_cpu_affinity auto 绑定 CPU 核心，减少跨核缓存失效和上下文切换
- 通过 systemd service 文件 统一控制：
[Service]
Nice=-5
CPUSchedulingPolicy=other - 配合 CPUQuota=80% 设置硬性资源上限，从源头隔离干扰
