直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能完成基础且可靠的 CPU 亲和性设置，前提是 Nginx 版本 ≥ 1.9.10；该组合自动读取逻辑 CPU 数并一对一绑定到 CPU 0、1、2…，适用于物理机和标准容器环境，但在 Kubernetes 中需先确认容器实际 vCPU 数，否则易因误读宿主机核数导致过载。
直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能完成基础且可靠的 CPU 亲和性设置，前提是 Nginx 版本 ≥ 1.9.10 —— 这是当前最推荐的起点，不是“可选项”，而是默认应启用的配置。
CPU 亲和性配置的核心写法
两行配置放在 nginx.conf 的全局块（events 块外、http 块之上）即可：
-
worker_processes auto;：自动读取当前环境可用的逻辑 CPU 数（如容器中受限，会读取 cgroup 限制后的值） -
worker_cpu_affinity auto;：按顺序将每个 worker 进程一对一绑定到 CPU 0、1、2…，避免跨核调度
该组合在物理机、标准虚拟机或资源明确的容器中效果稳定；若部署在 Kubernetes 等环境中，需先确认容器实际分配的 vCPU 数（例如用 cat /sys/fs/cgroup/cpu.max 或 nproc），否则 auto 可能误读宿主机核数，导致进程数过多、争抢加剧。
什么情况下要手动配置？
当遇到 NUMA 架构（如双路服务器）、需要精细控制资源隔离，或 auto 不生效时，才转向手动模式：
- 先查真实拓扑：
numactl --hardware看节点分布，lscpu看 CPU ID 与 node 对应关系 - 设
worker_processes为单个 NUMA 节点的逻辑核数（例如 node0 有 32 核，则设worker_processes 32） - 掩码位宽必须等于 worker 数量，每位对应一个 CPU ID（从右往左编号为 0、1…），例如 4 核写成
0001 0010 0100 1000 - 双路 64 核（node0: 0–31, node1: 32–63）应分两组写，确保所有 worker 都落在同一节点内，不能混用
必须验证是否真正生效
配置写对不等于生效。重启 Nginx 后，用以下命令交叉验证：
-
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n：每个 worker 的 PSR 列应为固定数字（如 0、1、2、3），不重复、不跳变 -
taskset -cp <pid>：输出类似pid 12345's current affinity list: 2，表示绑定到 core 2 - 若多个 worker 显示同一 PSR，常见原因包括：Nginx 版本过低、
worker_processes未设为具体数值（手动模式下）、cgroup 限制了 CPU 可见性
配套调优缺一不可
CPU 绑定只是性能底座，没有系统级配合，效果会大打折扣：
- 文件描述符：配置
worker_rlimit_nofile 65535;，并确保启动前执行ulimit -n 65535 - 内核连接队列：
net.core.somaxconn = 65535（写入/etc/sysctl.conf并sysctl -p） - 禁用 swap：
swapoff -a，防止 TLS 加解密等内存敏感操作被换出 - 网卡软中断绑定：将
softirq绑定到与 Nginx worker 相同的核心，减少跨核数据搬运
