nginx进程优先级不能靠worker_priority一键提升，它仅尝试设置nice值，生效必须同时满足四个前提：root启动或CAP_SYS_NICE、limits.conf配置priority限制、nginx.conf中启用worker_rlimit_priority、运行于Linux；推荐设为-5，须用ps验证ni值并实测延迟。
nginx 进程优先级不能靠单个参数“一键提升”，它本质是设置 Linux 的 nice 值，是否生效取决于系统权限、策略配置和运行环境。多数情况下，直接配 worker_priority 会静默失败——必须同时满足四个硬性条件，否则 ps 看到的 ni 值永远是 0。
worker_priority 生效的四个必要前提
缺一不可，否则配置无效：
- Nginx 必须以 root 用户启动，或容器中显式添加
--cap-add=SYS_NICE（普通用户无法设负值） -
/etc/security/limits.conf中为 nginx 用户配置 priority 限制，例如：
nginx soft priority 10
nginx hard priority 15 - nginx.conf 主配置块（main context）中必须启用资源限制指令：
worker_rlimit_priority 10（数值需 ≥ 你打算设的worker_priority） - 运行环境必须是 Linux；Windows/macOS 下该指令被完全忽略，systemd 管理时还可能被
Nice=覆盖
正确配置与取值建议
在满足上述前提后，才可在 nginx.conf 最外层添加：
- worker_priority -5;（推荐起始值，物理机独占部署可试 -7）
- 避免设 ≤ -10：内核线程默认 -5，systemd 服务常见 -10，再压低易导致 SSH 卡顿、监控失联、MySQL 心跳超时
- 混合部署时（如共机运行 MySQL），先查其 nice 值：
ps -o pid,ni,comm -C mysqld，Nginx 设为比它高 3～5 即可（如 MySQL 是 -5，则 Nginx 设 -2 或 0）
更可靠、更推荐的替代方式
相比依赖脆弱权限链的 worker_priority，以下方法落地稳定、效果明确：
- 用
worker_cpu_affinity auto;绑定 CPU 核心，减少跨核缓存失效和上下文切换抖动 - 通过 systemd 统一管控：在
/etc/systemd/system/nginx.service.d/override.conf中写：
[Service]
Nice=-5
CPUAffinity=0-3
CPUQuota=80% - 若需请求级逻辑优先，Nginx 本身不支持原生插队，但可用
limit_req分级限流 +upstream least_conn+proxy_buffering off组合实现高优路径快速响应
必须验证，不能只看 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 或延迟无改善，说明前提未满足，或当前场景下收益本就微弱
