在KVM虚拟化环境中，Nginx的worker_cpu_affinity必须基于虚拟机内实际逻辑CPU拓扑配置：先用lscpu或cat /sys/devices/system/cpu/online确认逻辑核数与编号（如0-3），再使掩码组数等于worker_processes、每组位数等于逻辑核总数、LSB对应core 0；严禁照搬宿主机掩码，否则导致启动失败或性能下降。
在 KVM 虚拟化环境中，Nginx 的 worker_cpu_affinity 配置不能照搬物理机方案——因为虚拟机看到的 CPU 拓扑（socket/core/thread 数量及编号）往往与宿主机不同，直接套用物理机掩码会导致绑定失败、启动报错，甚至性能反降。关键不是“怎么写掩码”，而是“先看清虚拟机里到底有几个逻辑核、它们怎么编号”。
确认虚拟机内部真实 CPU 拓扑
登录 Windows 或 Linux 虚拟机后，必须以客户机视角获取拓扑信息：
- Linux 虚拟机：运行
lscpu或nproc查逻辑 CPU 总数；再看cat /sys/devices/system/cpu/online确认启用范围（如0-3表示 4 个逻辑核，编号为 0、1、2、3） - Windows 虚拟机：打开任务管理器 → “性能”页 → 点击“CPU”，右下角显示“逻辑处理器：X 个”；若只显示 2 个，说明 KVM 未正确暴露拓扑（需先修正 XML 中的
vcpu+cpu mode='host-passthrough'+topology配置） - 特别注意：KVM 默认可能把多个 vCPU 映射到同一 socket 下的多个 core，或错误启用超线程模拟。务必用
lscpu | grep -E "(Socket|Core|Thread)"查清层级关系
按虚拟拓扑生成匹配的掩码组
掩码必须满足两个硬约束：组数 = worker_processes 值，每组位数 = 虚拟机逻辑 CPU 总数，且 LSB 对应 core 0。
- 若虚拟机识别出 4 个逻辑核（0–3），且你设
worker_processes 4，则配：worker_cpu_affinity 0001 0010 0100 1000; - 若虚拟机是 2 socket × 2 core × 1 thread = 4 vCPU，但编号顺序为 socket0-core0、socket0-core1、socket1-core0、socket1-core1，则编号仍是 0、1、2、3，掩码不变
- 若虚拟机只有 2 个逻辑核（常见于未调优的 Windows VM），不要强行配 4 组掩码，否则 Nginx 启动失败报 “invalid number of masks”。此时应设
worker_processes 2，再配worker_cpu_affinity 01 10;
避开虚拟化专属陷阱
KVM 环境下几个高频错误配置：
- 在容器或轻量级 VM 中误用宿主机掩码（如宿主机 64 核，虚拟机只分到 4 核，却填了 64 位掩码）→ 直接截断失效
- 启用了
worker_processes auto却配手动worker_cpu_affinity→ Nginx 无法对齐数量，报错或静默降级 - 使用
auto模式时忽略虚拟化限制：虽然worker_cpu_affinity auto在 1.9.10+ 支持自动适配，但在某些 KVM 配置下（如未透出 topology），它可能回退为单核绑定。建议首次部署仍用显式掩码并验证
验证绑定是否真正生效
光写对配置不够，必须进虚拟机验证：
- Linux 虚拟机：执行
ps -eo pid,comm,psr | grep nginx，检查每个 worker 进程的psr列是否稳定落在预期核心上（如 0、1、2、3） - 更可靠方式：取任一 worker PID（如
pgrep -f "nginx: worker"），运行taskset -p PID，输出应显示对应十六进制掩码（如0x00000001表示只允许 core 0） - Windows 虚拟机暂不支持
taskset，可借助 Process Explorer 工具查看进程关联性（Affinity），确认其被锁定在指定逻辑处理器
