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 块（最外层），例如：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

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 会被覆盖，纯冗余）

不复杂但容易忽略