直接用 worker_processes auto; 和 worker_cpu_affinity auto; 即可解决大多数场景的 cpu 亲和性问题，nginx 1.9.10+ 自动按逻辑 cpu 数一对一绑定 worker 进程至核心，但需验证生效并确保配套资源（如文件描述符、内核参数）到位。
直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能解决大多数场景的 CPU 亲和性问题。重点不是写对语法，而是确认它真生效、且配套资源没拖后腿。
优先启用 auto 模式
Nginx 1.9.10 及以上版本支持自动绑定，这是最稳妥的起点：
- 配置只需两行，放在 nginx.conf 的全局块（events 块外、http 块之上）
- 它会自动读取逻辑 CPU 数量，并为每个 worker 进程分配一个唯一核心，按顺序一对一绑定（CPU0、CPU1…）
- 适用于物理机和标准容器环境；若在 Kubernetes 等受限环境中，需先确认容器实际可访问的 CPU 数，否则 auto 可能误判
手动配置要对得上硬件
当 auto 不生效或需精细控制（如 NUMA 架构），才考虑手动设置：
- 先查真实 CPU 分布：
lscpu或cat /proc/cpuinfo | grep "processor\|core id\|physical id" - 掩码位数必须等于逻辑 CPU 总数：例如 4 核无超线程 → 4 位掩码；8 核 16 线程 → 16 位掩码
- 每个 worker 对应一个独立掩码，且只置一位：如
0001 0010 0100 1000表示 4 个 worker 分别绑定 core 0–3 - 双路服务器（NUMA）下，避免跨 CPU 插槽绑定。可用
numactl --hardware查节点，再限定所有 worker 绑定在同一 node 内
必须验证是否真正绑定
写了配置不验证，等于没调优：
- 检查进程与 CPU 的对应关系：
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n
输出中每个 worker PID 应固定对应一个 PSR 值（如 0、1、2、3），不能重复、不能跳变 - 查某进程当前绑定核：
taskset -cp <pid></pid>，应显示类似pid 12345's current affinity list: 2 - 若发现多个 worker 共享同一 PSR，常见原因有：Nginx 版本低于 1.9.10、worker_processes 未设为具体数值（非 auto 时才支持该指令）、cgroup 限制了 CPU 可见性
配套参数一个都不能少
CPU 绑定只是性能底座，没有资源保障，绑得再准也跑不动：
- 文件描述符上限：
worker_rlimit_nofile 65535;，并同步调大系统级限制：ulimit -n 65535 - 内核连接队列：
net.core.somaxconn = 65535（写入并生效） - 内存交换抑制：
vm.swappiness = 0，防止 HTTPS 加密过程因内存压力触发 swap - HTTPS 场景尤其要注意：TLS 握手和 AES/ChaCha20 加解密高度依赖 L1/L2 缓存热度，跨核迁移会导致缓存失效
