Nginx HTTPS高并发下CPU亲和性调优至关重要：TLS握手与加密高度依赖L1/L2缓存和TLB热度，进程跨核迁移会导致缓存失效、分支预测重置及内存延迟激增；推荐配置worker_processes auto; worker_cpu_affinity auto; 并验证PID与PSR严格一一对应，同时必须同步调高ulimit -n、net.core.somaxconn和降低vm.swappiness以保障效果。
在高并发 HTTPS 场景下，Nginx 的 CPU 亲和性调优不是“锦上添花”，而是直接影响 TLS 握手吞吐、请求延迟稳定性和 CPU 缓存命中率的关键动作。HTTPS 带来的额外开销（如 RSA/ECC 密钥交换、AES 加解密、证书验证）让每个 worker 进程更依赖本地 L1/L2 缓存和 TLB 热度；一旦进程被调度器频繁迁移，缓存失效会显著拖慢 SSL handshake 和加密运算速度。
为什么 HTTPS 场景对 CPU 亲和性更敏感
HTTPS 请求相比 HTTP 多出大量 CPU 密集型操作：
- TLS 握手阶段需执行非对称加解密（如 ECDSA 签名验签、ECDH 密钥协商），高度依赖 CPU 寄存器和 L1 数据缓存
- 握手后对称加密（AES-GCM、ChaCha20）需持续访问密钥、IV 和轮密钥表，这些数据若常驻 L1/L2 可减少 3–5 倍内存延迟
- OCSP Stapling、证书链验证、SNI 匹配等逻辑涉及频繁的内存读取与分支预测，跨核迁移会导致分支预测器重置和 TLB miss 激增
- perf top 显示，在未绑核的 HTTPS 高负载下，schedule() 和 __do_softirq 占比常超 15%，而绑核后可压至 3% 以内
推荐配置：优先用 auto，但要确认生效
worker_processes auto; 和 worker_cpu_affinity auto; 是 Nginx 1.9.10+（含当前主流 1.30 版本）最稳妥的起点。它会自动完成两件事：
- 将 worker 进程数设为逻辑 CPU 核心数（含超线程）
- 按顺序一对一绑定到 CPU0、CPU1……CPU
，避免多个 worker 争抢同一核心
验证是否生效：
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n输出应显示每个 worker PID 固定对应一个 PSR（CPU 号），且编号连续不重复。若出现多个 worker 共享同一 PSR，说明 auto 未按预期工作——常见于容器环境或 cgroup 限制了可用 CPU，此时需手动指定。
手动配置要点：掩码写法与 NUMA 意识
当必须手动配置时，关键不是“怎么写对”，而是“为什么这么写”：
- 掩码位数 = 逻辑 CPU 总数。例如 8 核 16 线程服务器，需 16 位掩码；4 核无超线程则用 4 位
- 每个 worker 对应一个独立掩码，且仅置 1 位（如 0001 0010 0100 1000），确保严格单核绑定
- NUMA 架构（双路/多路服务器）下，先运行 numactl --hardware 查节点分布；再让所有 worker 绑定在同一 NUMA 节点内（如 Node 0 的 CPU 0–7），避免跨节点内存访问带来 60–100ns 额外延迟
- 若启用了超线程（HT），不建议将两个 worker 绑定到同一物理核的两个逻辑 CPU（如 CPU0/CPU8），因共享执行单元反而可能降低 TLS 并发性能
配套必须调整的系统级参数
CPU 亲和性只是冰山一角，以下三项不调，绑核效果大打折扣：
- ulimit -n 65535：确保每个 worker 能打开足够文件描述符（HTTPS 连接 + SSL session cache + upstream sockets）
- net.core.somaxconn = 65535：提升 accept 队列长度，应对 TLS 握手突发连接
- vm.swappiness = 1：防止内存压力下 swap 触发，导致 worker 进程被换出，彻底破坏 CPU 亲和性
这些需写入 /etc/security/limits.conf 和 /etc/sysctl.conf，并重启 nginx 生效。
