直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能完成绝大多数场景下的自动调优，前提是 nginx 版本 ≥ 1.9.10，且系统资源配置同步到位；该组合自动读取逻辑 cpu 数并一对一绑定核心，需放在全局块、验证绑定效果、配套调优文件描述符与内核参数。
直接用 worker_processes auto; 和 worker_cpu_affinity auto; 就能完成绝大多数场景下的自动调优，前提是 Nginx 版本 ≥ 1.9.10，且系统资源配置同步到位。
CPU 自动识别与进程绑定
Nginx 1.9.10 起支持全自动亲和性分配：它读取系统逻辑 CPU 总数（如 8 线程就启 8 个 worker），并按顺序一对一绑定到核心（CPU0、CPU1…CPU7）。这个过程无需人工计算掩码，也不依赖超线程是否开启——只要 worker_processes 设为 auto，worker_cpu_affinity auto 才会生效。
- 配置必须放在全局块（
events外、http上），不能嵌套在其他块内 - 容器环境需确认实际可见 CPU 数（如 Kubernetes 中通过
lscpu或cat /sys/fs/cgroup/cpuset.cpus验证），否则auto可能误判 - 若物理机是双路 NUMA 架构，
auto默认不感知节点边界，此时需手动限定范围或配合numactl
验证是否真正生效
写了配置不验证，等于没调。关键看两点：
- 执行
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n，输出中每个 worker PID 应稳定对应一个唯一 PSR 值（如 0、1、2、3），不能重复也不能跳变 - 挑一个 worker 进程 PID，运行
taskset -cp <pid></pid>，返回应类似pid 12345's current affinity list: 2 - 若多个 worker 显示同一 PSR，常见原因包括：Nginx 版本过低、
worker_processes没设为具体数字或auto、cgroup 限制了 CPU 可见性
配套资源必须同步跟上
CPU 绑定只是底座，没有资源支撑，再准的绑定也跑不动：
- 文件描述符：在 nginx.conf 中加
worker_rlimit_nofile 65535;，同时系统级设置ulimit -n 65535并写入/etc/security/limits.conf - 内核连接队列：
net.core.somaxconn = 65535，写入/etc/sysctl.conf后执行sysctl -p - 内存交换抑制：
vm.swappiness = 0，避免 TLS 加解密时因内存压力触发 swap，导致缓存失效
特殊场景下的微调建议
当 auto 不适用时才考虑手动干预：
- NUMA 架构下，先用
numactl --hardware查清节点分布，然后只启用单 node 的物理核数（如双路 32 核，每路 16 核 →worker_processes 16），再用numactl --cpunodebind=0 --membind=0 nginx启动 - 高 HTTPS 流量场景，TLS 握手和加密运算对 L1/L2 缓存敏感，务必确保 worker 不跨核迁移，绑定后观察 P99 延迟是否收敛
- 若网卡支持多队列，还需配合 RPS 分流软中断：查队列数
ethtool -l eth0，启用ethtool -L eth0 combined N，再向/sys/class/net/eth0/queues/rx-0/rps_cpus写入对应掩码（如 8 核写ff）
