nginx单独配置worker_processes和worker_priority不能确保调度权重提升，必须同时满足：root权限启动（或cap_sys_nice）、limits.conf设priority限制、主块配置worker_rlimit_priority≥worker_priority、且运行于linux；否则ps查看ni值恒为0。
单独配 worker_processes 和 worker_priority 并不能让 Nginx 工作进程真正获得更高调度权重。前者只控制启动几个 worker，后者只是“尝试”设置 nice 值——是否生效、是否影响实际响应，取决于系统级权限和策略配置，不是写进去就起作用。
必须同时满足的四个前提
缺一不可，否则 ps -o pid,ni,comm -C nginx | grep worker 看到的 ni 值永远是 0：
- Nginx 必须以 root 用户启动，或容器中显式添加
--cap-add=SYS_NICE（普通用户无法设负 nice） -
/etc/security/limits.conf中为 nginx 用户配置 priority 限制，例如：
nginx soft priority 10
nginx hard priority 15 - Nginx 配置主块（main context）中必须启用：
worker_rlimit_priority 10（数值需 ≥ 你设的worker_priority） - 运行环境必须是 Linux；Windows/macOS 下该指令被忽略，systemd 管理时还可能被
Nice=覆盖
合理取值与风险边界
目标不是压垮其他进程，而是让 worker 在 CPU 竞争中更稳地响应请求：
- 推荐范围：-5 到 -7——物理机独占部署下有可测收益
- 避免 ≤ -10：systemd 默认 -10，内核线程默认 -5，再压低易导致 SSH 卡顿、监控失联、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 进程，ni 列必须严格等于你配置的值（master 的 ni 无意义） - 用
stress-ng --cpu 4 --timeout 30s拉满 CPU，同时持续curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost，对比 P95 延迟波动是否收窄
比 worker_priority 更可靠的做法
与其花时间调试一个易失效的参数，不如做这些真正可控的事：
- 用
worker_cpu_affinity auto绑定 CPU 核心，减少跨核缓存失效和上下文切换 - 通过 systemd service 文件统一控制：
[Service]
Nice=-5
CPUSchedulingPolicy=other
CPUQuota=80%——从源头隔离干扰 - 关闭
accept_mutex on（默认已 off），启用multi_accept on，配合 epoll 提升突发连接吞吐一致性
