worker_priority不能直接调整nginx全局进程优先级，仅尝试设置nice值，生效须同时满足四前提：root启动或cap_sys_nice、limits.conf配置priority限制、nginx.conf中显式设置worker_rlimit_priority、运行于linux；推荐取值-5至-10，需用ps验证ni值并结合高负载测试延迟变化。
worker_priority 本身不能直接“调整 Nginx 在全局系统中的进程优先级”，它只是尝试设置 Linux 的 nice 值，而该值是否真正生效、是否影响调度行为，取决于四个硬性前提是否全部满足。多数生产环境（尤其是容器化、systemd 管理、共享主机）下，这个指令实际不起作用，设了也白设。
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 而不配此项，完全无效）
- 运行环境必须是 Linux；Windows/macOS 下该指令被忽略，systemd 管理时还可能被 Nice= 配置覆盖
取值要克制，别迷信负数越大越好
目标不是压垮其他进程，而是让 Nginx 在 CPU 竞争中更稳地响应请求：
- 推荐范围：-5 到 -10 —— 这类值在物理机、裸金属、单一服务场景下有可测收益
- 避免 -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 进程，master 的 ni 值无意义；输出 ni 列必须严格等于你配置的值（比如配了 -5，就必须看到 -5）
- 用 stress-ng --cpu 4 --timeout 30s 拉满 CPU，同时用 curl 测延迟波动（关注 P95），对比调优前后变化
比 worker_priority 更可靠的做法
与其花时间调试一个易失效的参数，不如做这些真正可控的事：
- 用 worker_cpu_affinity auto 绑定 CPU 核心，减少跨核缓存失效和上下文切换
- 通过 systemd service 文件统一控制：Nice=-5 + CPUSchedulingPolicy=other，比 Nginx 内部配置更稳定、可审计
- 限制资源竞争：用 cgroups（如 systemd 的 CPUQuota）或容器平台限制其他服务 CPU 配额
- 调优连接模型：开启 multi_accept on、关闭 accept_mutex、确保使用 epoll
