worker_priority仅在linux下以root启动且满足权限与配置前提时，为worker进程设置nice值；它不影响master进程，推荐值为-5至-7，需用ps验证ni值并实测延迟。

worker_priority 不作用于 Master 进程，也不直接调整 Master 派生的子进程（即 worker 进程）的系统优先级——它只在满足全部前提时，尝试为 worker 进程 设置 Linux 的 nice 值。Master 进程的 ni 值始终不受该指令影响，且其调度行为与 worker 无关。

真正起作用的对象是 worker 进程

nginx 启动后，master 进程负责管理，实际处理请求的是由它 fork 出来的 worker 进程。worker_priority 的目标就是让这些 worker 在 CPU 竞争中更早被调度，但前提是：

• nginx 必须以 root 启动，或容器中添加 --cap-add=SYS_NICE
• /etc/security/limits.conf 中为 nginx 用户配置：
  nginx soft priority 10
nginx hard priority 15
• nginx.conf 中必须启用：worker_rlimit_priority 10（数值 ≥ 你设的 worker_priority）
• 运行环境为 Linux；systemd 管理时还可能被 Nice= 覆盖

配置写法与典型值

在 nginx.conf 的全局块（main context）中添加：

Nginx Hosting

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

下载

worker_processes auto;
worker_priority -5;
worker_rlimit_priority 10;

推荐取值范围为 -5 到 -7。设为 -10 或更低容易导致 ssh、监控 agent、数据库等关键进程响应变慢，尤其在混合部署场景下。

验证是否真正生效

reload 配置后，不能只看是否成功，必须实测：

• 执行：ps -o pid,ni,comm -C nginx | grep worker
  输出中 ni 列必须严格等于你配置的值（如 -5），master 进程的 ni 值无意义
• 用 stress-ng --cpu 4 --timeout 30s 制造高负载，同时用 curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost 测延迟波动，观察 P95 是否收窄

比 worker_priority 更稳定的做法

多数生产环境（尤其是容器、systemd、共享主机）下，worker_priority 很难生效。更可靠的方式是：

• 用 worker_cpu_affinity auto; 绑定 worker 到不同 CPU 核心，减少上下文切换开销
• 通过 systemd service 文件统一控制：Nice=-5 + CPUSchedulingPolicy=other
• 启用 use epoll; 和 listen 80 reuseport; 提升连接分发效率
• 对非关键服务做 CPU 限流，例如 systemd 中设置 CPUQuota=70%