推荐直接在nginx.conf全局块配置worker_processes auto;和worker_cpu_affinity auto;，适用于Nginx≥1.9.10，自动按物理核顺序一对一绑定worker进程，避免缓存抖动，适配物理机、虚拟机及资源明确的容器环境。
直接在 nginx.conf 全局块（events 块外、http 块之上）写两行配置即可完成基础且可靠的 CPU 亲和力设置：worker_processes auto; 和 worker_cpu_affinity auto;。前提是 Nginx 版本 ≥ 1.9.10，这是当前最推荐的默认做法，不是可选项。
用 auto 模式快速启用（推荐起点）
这两行配置自动协同工作：
- worker_processes auto;：读取当前环境实际可用的逻辑 CPU 数（容器中会尊重 cgroup 限制，Kubernetes 下需提前确认 vCPU 数，否则可能误读宿主机核数）
- worker_cpu_affinity auto;：按顺序将每个 worker 进程一对一绑定到 CPU 0、1、2…，避免跨核调度和缓存抖动
适用于物理机、标准虚拟机及资源明确的容器环境。无需手动计算掩码，也无需硬编码核心数，适配性好、出错率低。
需要手动配置的典型场景
仅当遇到以下情况时才转向手动模式：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- NUMA 架构（如双路服务器），需让所有 worker 落在同一 NUMA node 内以减少远程内存访问
- 要严格隔离资源（例如与数据库共机时预留部分核心）
- auto 模式不生效（常见于版本过低或 cgroup 限制干扰）
手动配置前务必先查真实拓扑：lscpu 看 CPU ID 分布，numactl --hardware 看节点划分；掩码位宽必须等于 worker_processes 数值，每位对应一个 CPU ID（从右往左编号为 0、1…），例如 4 核写成 0001 0010 0100 1000；双路 64 核应分组写，禁止跨插槽混绑。
验证是否真正生效
配置写对 ≠ 绑定成功，必须交叉验证：
-
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并生效 -
内存交换抑制：设
vm.swappiness = 0，防止 TLS 加解密因内存压力触发 swap -
事件处理优化：确认
accept_mutex off;（1.11.3+ 默认关闭），开启multi_accept on;
