worker_priority不能确保高负载下静态资源分发流畅，必须先绑定CPU核心（如worker_cpu_affinity auto），再满足root权限、limits.conf限制、worker_rlimit_priority启用及Linux环境四前提，取值-5至-8并验证ni值与延迟改善才有效。
worker_priority 不能确保静态资源分发在高负载时“流畅”，它不提供资源隔离、不绑定 CPU、也不改变进程执行位置。真正影响静态分发稳定性的，是确定性调度路径和资源划界，而非优先级数字本身。
核心前提：先绑核，再谈优先级
静态资源分发依赖的是可预测的执行环境。如果 worker 进程在不同 CPU 核之间频繁迁移，缓存失效、上下文切换开销会直接抵消任何 nice 值优化的效果。
- 启用自动绑核：worker_cpu_affinity auto;（Linux 4.0+，每个 worker 独占一个物理核）
- 手动指定更精确：worker_cpu_affinity 0001 0010 0100 1000;（适用于 4 核，避免超线程干扰）
- 确认生效：taskset -cp <worker_pid> 查看实际绑定情况
worker_priority 生效的四个硬条件
该配置仅在全部满足以下条件时，才可能让 worker 的 nice 值真实降低（即获得更高调度权重）：
- 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 下完全无效
合理取值与验证方式
目标不是压垮其他服务，而是让 Nginx worker 在 CPU 抢占中略占优势。推荐范围是 -5 到 -8，足够改善 P95 延迟（实测通常下降 10%～20%），又不会拖慢 SSH、监控或数据库等关键进程。
- 配置示例：worker_priority -6;
- 重启后验证：ps -o pid,ni,comm -C nginx | grep worker —— ni 列应显示 -6
- 压力测试验证：stress-ng --cpu 8 --timeout 60s 拉满 CPU，同时用 ab -n 10000 -c 100 http://localhost/xxx.jpg 测静态文件响应延迟波动
比 worker_priority 更可靠的做法
在多数生产场景中，系统级管控比 Nginx 内部配置更稳定、副作用更小：
- 通过 systemd 统一设置：Nice=-5 + CPUSchedulingPolicy=other（写入 /etc/systemd/system/nginx.service.d/override.conf）
- 启用高效连接模型：multi_accept on; 和 accept_mutex off;，减少连接排队等待
- 配合 cgroups v2 限制其他服务 CPU 使用率，为 Nginx 预留资源带宽，比争抢优先级更可控
