应优先通过 systemd 的 Nice= 参数调整 Nginx worker 进程优先级，最可靠；仅当必须时才用 worker_priority，且须满足 root 启动、limits 配置、worker_rlimit_priority 启用及 Linux 环境四条件。
调整 Nginx 对请求处理的进程优先级，本质是调整其 worker 进程 在操作系统 CPU 调度队列中的相对地位，不是给单个 HTTP 请求设“高优/低优”，而是让整个 worker 更快抢到 CPU 时间片。关键要分清两层：系统级调度（真正起效）和 Nginx 配置级尝试（常被忽略或失效）。
优先用 systemd 统一控制（最可靠）
如果你用 systemd 管理 Nginx（绝大多数现代 Linux 发行版默认如此），直接在服务配置里设 Nice 值，worker 进程会自动继承 master 的调度优先级，无需碰 Nginx 配置文件：
- 运行
sudo systemctl edit nginx，创建覆盖文件 - 写入：
[Service] Nice=-5 LimitNICE=-10
- 执行
sudo systemctl daemon-reload && sudo systemctl restart nginx - 验证：
ps -o pid,comm,nice -C nginx | grep worker—— ni 列应为 -5
仅当必须用 Nginx 配置时才设 worker_priority
该指令只在满足全部四个条件时才可能生效，否则设了也白设：
- Nginx 必须以 root 启动，或容器中加
--cap-add=SYS_NICE -
/etc/security/limits.conf中为 nginx 用户配好 priority 限制（如nginx soft priority 10） -
nginx.conf全局块中显式启用worker_rlimit_priority 10（数值 ≥ worker_priority） - 运行在 Linux 上；systemd 环境下还可能被
Nice=覆盖
若确认满足，可在 main 块中加：
worker_processes auto;<br> worker_rlimit_priority 10;<br> worker_priority -5;
重启后仍需用
ps 验证 ni 值是否真变。
比调优先级更有效的做法
盲目压低 nice 值收益小、风险大（SSH 卡顿、MySQL 心跳超时）。实际更值得做的是：
-
绑定 CPU 核心：加
worker_cpu_affinity auto;，减少跨核缓存失效 -
优化连接模型：启用
multi_accept on;和accept_mutex off;（配合 epoll） -
避免混部干扰：若与 MySQL 共机，先查
ps -o pid,ni,comm -C mysqld，Nginx 设为比它高 3～5 即可（例如 MySQL 是 -5，Nginx 设 0）
不建议碰的场景
以下情况请放弃 worker_priority，它基本不起作用：
- Docker/Kubernetes 容器部署（默认无 CAP_SYS_NICE，cgroup 限频更有效）
- 云主机或共享服务器（影响他人或被宿主策略拦截）
- 已用
worker_cpu_affinity绑核（优先级收益趋近于零） - systemd 管理但没配
Nice=（此时 Nginx 自己设的值会被忽略）
