大型服务器上配置 Nginx CPU 亲和力的核心是让每个 worker 稳定独占物理核心、避开超线程、适配 NUMA 架构并验证生效；推荐优先使用 worker_processes auto 和 worker_cpu_affinity auto（≥1.9.10），仅在需预留核心或限定 NUMA node 时手动配置，且掩码位宽须等于 worker_processes 数、从右往左对应 CPU ID，并配合 numactl 启动与多参数调优确保效果。
大型服务器上配置 Nginx 的 CPU 亲和力，核心不是“多写几组掩码”，而是让每个 worker 稳定独占一个物理核心、避开超线程干扰、适配 NUMA 架构，并验证真实生效。Nginx ≥ 1.9.10 后，推荐起点就是 auto 模式，它自动适配物理核数与拓扑，比手动计算更可靠、更少出错。
先确认真实 CPU 拓扑，再决定怎么绑
别直接套用“32 核就写 32 个掩码”。先运行：
-
lscpu | grep -E "(CPU\(s\)|Core|Socket|NUMA)"—— 看清逻辑核总数、物理核分布、插槽数和 NUMA 节点数 -
numactl --hardware—— 查每个 NUMA node 包含哪些 CPU ID（例如 node 0: 0-15，node 1: 16-31）
如果输出显示 2 Socket(s), 16 Core(s) per socket, NUMA node(s): 2，说明是双路服务器，共 32 物理核、分属两个节点。此时应优先让所有 worker 落在同一 NUMA node 内（比如只用 node 0 的 core 0–15），避免跨节点访问内存带来的延迟飙升。
auto 模式是大型服务器的默认首选
在 nginx.conf 全局块（events 块外、http 块之上）写两行即可：
-
worker_processes auto;—— 自动读取当前环境可见的逻辑 CPU 数（容器中会尊重 cgroup 限制） -
worker_cpu_affinity auto;—— 按物理核顺序一对一绑定，跳过超线程副核，天然适配 NUMA 和虚拟化环境
该组合等价于手动写出完整掩码，但无需硬编码、不因超线程误判、不被宿主机核数误导（Kubernetes 中尤其关键）。仅当需预留核心给数据库、或严格限定某 NUMA node 时，才转向手动模式。
手动配置必须严格对齐物理核位序
若必须手动写，记住三件事：
- 掩码位宽 =
worker_processes数值，每位从右往左对应 CPU 0、CPU 1、CPU 2…（0001是 core 0，1000是 core 3） - 双路 32 核服务器，若只用 node 0 的 16 个物理核，应写成 16 组掩码：
0001 0010 ... 8000（十六进制更不易错：01 02 04 … 8000） - 禁止跨插槽混绑，例如不能把前 8 个 worker 绑 node 0、后 8 个绑 node 1——这会放大远程内存访问开销
验证是否真正绑定成功，不能只看配置写了没
配置写对 ≠ 进程真绑住了。必须交叉验证：
-
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n—— 每个 worker 的 PSR 列应为唯一、固定数字（如 0、1、2…15），不重复、不跳变 -
taskset -cp <pid>—— 返回类似pid 12345's current affinity list: 7，表示稳定落在 core 7 - 若多个 worker 显示同一 PSR，常见原因：Nginx 版本低于 1.9.10、
worker_processes没设为auto或具体数值、cgroup 隐藏了部分 CPU 可见性
配套参数必须同步到位，否则绑核效果归零
CPU 绑定只是性能底座，缺了这些支撑，反而可能降速：
- 关闭 accept 锁：
accept_mutex off;（Nginx ≥ 1.11.3 默认已关，确认无on） - 开启批量建连：
multi_accept on;（放在 events 块内） - 提升连接上限：
worker_rlimit_nofile 65535;+ 系统级ulimit -n 65535 - 扩大内核连接队列：
net.core.somaxconn = 65535（写入/etc/sysctl.conf并sysctl -p） - 抑制内存交换：
vm.swappiness = 0（防止 TLS 加解密触发 swap）
