worker_priority不能确保静态服务高负载下平稳，必须先绑定CPU核心（如worker_cpu_affinity auto），再满足root权限、limits.conf配置priority限制、worker_rlimit_priority启用及Linux环境四前提，取值-5至-8并验证ni值与延迟改善才有效。

worker_priority 不能确保静态服务在高负载下“平稳”，它只是尝试调整 Linux 进程的 nice 值，而该值是否生效、是否带来实际收益，取决于四个硬性前提是否全部满足。多数生产环境（尤其是容器化、非 root、systemd 管理）中，这个配置实际无效，甚至可能引发副作用。

必须先绑核，再谈优先级

静态资源分发依赖可预测的执行路径。如果 worker 进程在 CPU 核之间频繁迁移，缓存失效和上下文切换开销会直接抵消任何 nice 值优化。

• 启用自动绑核：worker_cpu_affinity auto;（Linux 4.0+，每个 worker 独占一个物理核）
• 手动绑定更可控（如 4 核服务器）：worker_cpu_affinity 0001 0010 0100 1000;
• 验证是否生效：taskset -cp $(pgrep -f "nginx: worker") 查看实际绑定情况

worker_priority 生效的四个前提缺一不可

设了 worker_priority -6 却发现 ps 显示 ni = 0？大概率是以下任一条件未满足：

• Nginx 必须以 root 启动，或容器中显式添加 --cap-add=SYS_NICE
• /etc/security/limits.conf 中为 nginx 用户配置：nginx soft priority 10 和 nginx hard priority 15
• Nginx 配置中必须有：worker_rlimit_priority 10（数值需 ≥ worker_priority）
• 运行环境必须是 Linux；Windows/macOS 下该指令完全被忽略

合理取值与验证方式

目标不是压垮其他服务，而是让 worker 在 CPU 抢占中略占优势，同时保障 SSH、监控、数据库等基础服务响应正常。

• 推荐范围：-5 到 -8 —— 实测 P95 延迟通常下降 10%～20%
• 避免设为 -15 或更低：systemd 默认 -10，内核线程常为 -5，再压低易导致运维通道卡顿
• 重启后验证：ps -o pid,ni,comm -C nginx | grep worker，只看 worker 进程的 ni 列是否等于配置值
• 压力测试验证：用 stress-ng --cpu 8 --timeout 60s 拉满 CPU，同时用 ab -n 10000 -c 100 http://localhost/xxx.jpg 测静态文件延迟波动

比 worker_priority 更可靠的做法

真正影响静态服务稳定性的，是资源划界与调度确定性，而非优先级数字本身。

• 通过 systemd 统一控制：Nice=-5 + CPUSchedulingPolicy=other（写入 /etc/systemd/system/nginx.service.d/override.conf）
• 启用高效连接模型：multi_accept on; 和 accept_mutex off;，减少排队等待
• 配合 cgroups v2 限制其他服务 CPU 使用率，防止突发任务打穿 Nginx 资源供给
• 确认 worker_rlimit_nofile 与系统 ulimit -n 匹配，避免 “too many open files” 导致请求被丢弃