worker_priority不能确保静态分发进程在负载抖动时“不受影响”，它仅是受限的nice值建议，真正稳定依赖CPU亲和性、cgroups资源划界与调度干扰抑制。
worker_priority 不能确保静态分发进程在负载抖动时“不受影响”，它不是隔离或保护机制，而是一个受限的 nice 值建议，且仅作用于 Nginx worker 进程本身。所谓“静态分发进程”（如固定绑定 CPU 的 worker）是否稳定，关键不在优先级，而在调度绑定与资源隔离。
真正影响静态分发稳定性的，是 CPU 亲和性、系统调度干扰、以及资源争抢。worker_priority 在此场景下既不提供隔离能力，也不改变进程归属或执行位置，盲目配置反而可能引入副作用。
下面从实际可落地的角度说明怎么做：
✅ 确保 worker 进程绑定 CPU 核心（核心前提）
静态分发依赖的是确定性执行位置，而非优先级高低：
- 使用
worker_cpu_affinity auto;（推荐）或显式绑定，例如：worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;
- 效果：每个 worker 固定运行在指定核心，避免跨核迁移、缓存失效和调度抖动。
- 注意：NUMA 架构下需配合
numactl或内核启动参数优化内存本地性。
✅ 控制系统级调度干扰（比调 nice 更有效）
负载剧烈抖动时，真正造成延迟波动的是其他进程抢占 CPU 或触发上下文切换：
- 用 systemd 服务文件统一设限（比 Nginx 内置配置更可靠）：
[Service] Nice=-5 CPUSchedulingPolicy=other CPUQuota=80%
- 或通过 cgroups v2 限制 Nginx 所在 slice 的 CPU 配额，防止被突发任务打穿。
- 关键点：
CPUQuota可保障最小可用算力，而Nice仅影响权重——前者才是抖动场景下的兜底手段。
❌ 不要依赖 worker_priority 做“保护”
它在绝大多数生产环境（容器、非 root、默认 SCHED_OTHER）下静默失效：
- 若未满足全部四个前提（root 启动 +
worker_rlimit_priority+/etc/security/limits.conf授权 + Linux 环境），设置worker_priority -10就等于没写； - 即使生效，nice 值只调整时间片比例，无法阻止高优先级实时进程（如音频、硬件中断线程）抢占；
- 更严重的是：设为
-15或更低，可能让 SSH、systemd-journald 等基础服务响应迟滞，反而放大抖动影响。
✅ 验证静态分发是否真稳定
不要只看配置，要观测运行态：
- 检查绑定效果：
taskset -cp $(pgrep -f "nginx: worker") | head -4
- 查看调度延迟（需
perf或rt-tests）：# 测量单个 worker 的最大延迟（毫秒级） sudo cyclictest -p 80 -t -n -i 1000 -l 10000 -D 60s
- 对比负载前后
mpstat -P ALL 1中各核心的%idle波动幅度——若某核心 idle 始终 >30%，说明绑定成功且未被强占。
本质上，静态分发的稳定性来自位置锁定 + 资源划界 + 干扰抑制，而不是靠调高一点 nice 值去“抢时间片”。把精力放在 worker_cpu_affinity、cgroups 配额、以及关闭 accept_mutex（减少锁竞争）上，收益明确、风险可控。
