worker_priority仅在四个前提全满足时才生效：root权限或sys_nice能力、/etc/security/limits.conf配置priority限制、启用worker_rlimit_priority指令、linux环境；推荐设为-5至-7，需用ps验证ni值并实测延迟改善。

worker_priority 不能直接“提升调度优先级”，它只是尝试设置 Linux 进程的 nice 值，而该值是否生效、是否影响实际调度，取决于四个硬性前提是否全部满足。多数生产环境（尤其是容器化、systemd 管理、非 root 启动）下，配置了也无效。

worker_priority 生效的四个必要条件

缺一不可：

• 必须以 root 启动 Nginx，或容器中显式添加 --cap-add=SYS_NICE；普通用户无法设负值，系统会静默忽略
• /etc/security/limits.conf 中必须为 nginx 用户配置 priority 限制，例如：
  nginx soft priority 10
nginx hard priority 15
• Nginx 配置中必须启用资源限制指令：
  worker_rlimit_priority 10;（数值需 ≥ 你设置的 worker_priority）
• 运行环境必须是 Linux；Windows/macOS 下该指令完全被忽略

合理取值与安全边界

目标不是压到最低，而是让 Nginx 在 CPU 争抢中更稳定响应，同时不挤占关键系统进程：

Nginx Hosting

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

下载

• 推荐范围：-5 到 -7；物理机独占部署且观察到 worker 常驻 ni = +5 或更高时可尝试
• 避免 -10 及更低：systemd 默认 -10，内核线程默认 -5，再压低易导致 SSH 登录卡顿、监控失联、健康检查失败
• 若与 MySQL/Redis 共机，先查其当前 nice 值（ps -o pid,ni,comm -C mysqld），Nginx 设为比它高 3～5 即可（如 MySQL 是 -5，则 Nginx 设 -2 或 0）

必须验证，不能只看 reload 成功

配置后必须分三步确认：

• 执行 ps -o pid,ni,comm -C nginx | grep worker —— 只看 worker 进程，ni 列必须严格等于你设置的值（如配了 -5，就必须看到 -5；master 进程的 ni 无意义）
• 在真实负载下测试：用 stress-ng --cpu 4 --timeout 30s 拉高 CPU，同时持续请求 curl -w "%{time_starttransfer}\n" -s -o /dev/null http://localhost，对比 P95 延迟波动是否收窄
• 若 ni 仍为 0 或延迟无改善，说明前提未满足，或收益本就微弱

比 worker_priority 更有效、更可控的做法

这些方法不依赖权限和系统策略，落地稳定、效果明确：

• 绑定 CPU 核心：worker_cpu_affinity auto; 减少跨核缓存失效和上下文切换抖动
• 用 systemd 统一管控：在 /etc/systemd/system/nginx.service.d/override.conf 中写：
  [Service]
Nice=-5
CPUAffinity=0-3
CPUQuota=80% —— 比 Nginx 内部配置更可靠，且兼容 cgroup v2
• 调优事件模型：use epoll; + multi_accept on; + accept_mutex off;，显著提升突发连接吞吐一致性
• 检查并匹配系统限制：worker_rlimit_nofile 必须 ≥ ulimit -n，否则出现 “too many open files” 会直接丢请求