worker_cpu_affinity 本身不直接解决多租户性能干扰，但可通过绑定 CPU 核心隔离 Nginx worker 进程，减少调度争抢、缓存污染和跨 NUMA 访问，为多租户提供资源边界基础；需配合 NUMA 绑定、中断亲和、流量分流及全链路验证才能实现真实隔离。
worker_cpu_affinity 本身不直接解决多租户环境下的性能干扰，但它能成为关键基础手段——通过隔离 Nginx worker 进程的 CPU 资源，减少租户间因调度争抢、缓存污染和跨 NUMA 访问引发的隐性干扰。
明确划分 CPU 核心资源边界在多租户场景（如 SaaS 网关、API 平台或容器化部署中多个业务共用一台 Nginx 实例），不同租户流量常由不同 server 块或 upstream 分组承载。若所有 worker 共享全部 CPU 核，高流量租户会频繁触发上下文切换，导致低优先级租户响应延迟升高、P99 毛刺明显。
合理做法是：按租户负载等级或 SLA 分配独占核心组。例如：为高保障租户（如金融类）预留 2 个物理核，启动专属 Nginx 实例并配置worker_cpu_affinity 00000011（绑定 core 0 和 1）
为普通租户聚合到另 4 个核，用另一实例配worker_cpu_affinity 00111100（绑定 core 2–5）
避免掩码重叠（如两个实例都写 00000011），否则仍会竞争同一物理资源配合 NUMA 拓扑与内存亲和性在多路服务器或启用了 NUMA 的虚拟机中，跨节点访问内存延迟可达 2–3 倍。仅绑 CPU 不够，还需确保：Nginx在宝塔面板中轻松管理Nginx高性能Web服务器。提供可视化配置反向代理、负载均衡、SSL证书及HTTP缓存功能，一键优化高并发性能，助您高效搭建稳定、快速的网站运行环境。
下载每个租户对应的 Nginx 实例运行在本地 NUMA 节点上（用numactl --cpunodebind=0 --membind=0nginx启动）
worker_processes 数 ≤ 绑定节点的逻辑核数，防止调度器跨节点迁移/proc/sys/kernel/numa_balancing 设为 0（关闭自动 NUMA 迁移），避免内核干扰手动绑定协同网络中断与租户流量分流CPU 绑定效果会被网卡软中断（ksoftirqd）破坏：若网卡收包中断跑在 core 0，而租户 A 的 worker 绑在 core 2，数据就得跨核搬运。
必须同步做：
用ethtool -L eth0 combined 8均匀分配队列数，再用echo 1 > /proc/irq/*/smp_affinity_list将每队列中断绑定到对应租户的 CPU 组（如租户 A 队列 → core 0,1）
结合 stream 模块或 geo 指令，把租户 IP 段哈希到特定 upstream 组，再配合 cpu_affinity 实现“请求入口→中断→worker→内存”全链路局部化验证租户级隔离是否真实生效不能只看单个 Nginx 实例的绑定结果，要交叉比对：对每个租户专用 Nginx 实例，分别执行：ps -eo pid,args,psr | grep 'nginx: worker' | grep -v master，确认 psr 列只落在预定核心范围内检查cat /proc/interrupts | grep eth0，确认各 RX/TX 队列中断分布与租户 CPU 组匹配用perf stat -e cycles,instructions,cache-misses -p [worker_pid]对比不同租户 worker 的 cache-miss ratio，隔离良好时应相差小于 15%