直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能解决大多数场景的 CPU 亲和性问题，这是 Nginx 1.9.10+ 默认应启用的起点配置，自动读取逻辑 CPU 数并一对一绑定至 CPU 0、1、2…，减少跨核调度开销；需置于 nginx.conf 全局块，容器中须先确认实际 vCPU 数（如用 nproc），否则易因误读宿主机核数导致过载。
直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能解决大多数场景的 CPU 亲和性问题。这不是“可选项”，而是 Nginx 1.9.10+ 版本下默认应启用的起点配置，它自动读取逻辑 CPU 数量，并为每个 worker 进程一对一绑定到 CPU 0、1、2…，显著减少跨核调度带来的缓存失效和上下文切换开销。
优先启用 auto 模式
两行配置放在 nginx.conf 的全局块（events 块外、http 块之上）即可：
-
worker_processes auto;：自动识别当前环境可用的逻辑 CPU 数；在容器中会读取 cgroup 限制后的值（如 Kubernetes 中需先确认/sys/fs/cgroup/cpu.max或运行nproc） -
worker_cpu_affinity auto;：按顺序将每个 worker 绑定到独立核心，例如 4 核即绑定至 core 0–3 - 适用于物理机、标准虚拟机及资源明确的容器环境；若部署在受限容器中，auto 可能误读宿主机核数，导致进程数过多、争抢加剧
手动配置要对得上硬件拓扑
当遇到 NUMA 架构、需要资源隔离或 auto 不生效时，才转向手动模式：
- 先查真实分布：
lscpu看逻辑 CPU ID 与 node 对应关系，numactl --hardware查 NUMA 节点划分 - 设
worker_processes为单个 NUMA 节点内的逻辑核数（如 node0 有 32 核，则设为 32） - 掩码位宽必须等于 worker 数量，每位对应一个 CPU ID（从右往左编号为 0、1…）；例如 4 核写成
0001 0010 0100 1000 - 双路服务器应分组配置，确保所有 worker 都落在同一 NUMA node 内，避免跨插槽访问内存
必须验证是否真正绑定成功
写了配置不验证，等于没调优：
- 查进程与 CPU 对应关系：
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 版本低于 1.9.10、
worker_processes未设为具体数值（手动模式下）、cgroup 限制了 CPU 可见性
配套参数一个都不能少
CPU 绑定只是性能底座，没有系统级配合，效果会大打折扣：
- 文件描述符上限：
worker_rlimit_nofile 65535;，并同步调大系统级限制：ulimit -n 65535 - 内核连接队列：
net.core.somaxconn = 65535（写入/etc/sysctl.conf并执行sysctl -p） - 内存交换抑制：
vm.swappiness = 0，防止 HTTPS 加密过程因内存压力触发 swap - HTTPS 场景尤其要注意：TLS 握手和 AES/ChaCha20 加解密高度依赖 L1/L2 缓存热度，跨核迁移会导致缓存失效
