Nginx worker进程优先级本质是Linux的nice值，影响内核调度权重；推荐用systemd的Nice=配置统一控制，worker_priority仅在root启动、配limits、设worker_rlimit_priority且未被覆盖时才可能生效。
Nginx 的 worker 进程优先级本质是 Linux 的 nice 值，它影响内核调度器分配 CPU 时间片的倾向——数值越小（如 -5），优先级越高；越大（如 10），越靠后。但要注意：这不是给单个 HTTP 请求设“高优”，而是调整整个 worker 进程在系统级的调度权重。
优先用 systemd 统一控制（最稳妥）
绝大多数现代 Linux 系统通过 systemd 管理 Nginx，这是唯一能稳定生效、无需改 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
这个方式让 master 进程以指定 nice 启动，所有 worker 自动继承，不依赖权限、limits 或 Nginx 内部配置，兼容容器外的所有常见部署。
只有满足全部条件才考虑 worker_priority
该指令写在 nginx.conf 的 main 块（最外层），例如：
worker_processes auto; worker_rlimit_priority 10; # 必须显式启用，且值 ≥ worker_priority worker_priority -5;
但它仅在四个条件同时满足时才可能生效：
- Nginx 以 root 启动，或容器中加
--cap-add=SYS_NICE -
/etc/security/limits.conf中为nginx用户配了 priority 限制，如：nginx soft priority 10 nginx hard priority 15
-
nginx.conf中已配置worker_rlimit_priority（仅写worker_priority不起作用） - 运行在 Linux 上，且未被 systemd 的
Nice=覆盖
设完必须用 ps 验证 ni 值是否真变，否则就是无效配置。
更值得做的其实是这些
调 nice 收益有限，还容易引发 SSH 卡顿、MySQL 心跳失败等问题。实际更有效的是：
- 启用
worker_cpu_affinity auto;—— 让每个 worker 绑定独立 CPU 核，减少缓存失效和上下文切换 - 使用
epoll+multi_accept on;+accept_mutex off;—— 提升事件分发效率 - 混合部署时，先查 MySQL 的
ps -o pid,ni,comm -C mysqld，再把 Nginx 设为比它高 3～5（例如 MySQL 是 -5，Nginx 设 0）
这些情况别碰 worker_priority
- Docker/K8s 容器环境（默认无
CAP_SYS_NICE，cgroup 限频更合理） - 云主机或共享服务器（宿主策略会拦截，还可能影响他人）
- 已绑核（
worker_cpu_affinity开启后，优先级调整几乎无收益） - systemd 环境下已设
Nice=（此时worker_priority会被覆盖，纯冗余）
不复杂但容易忽略
