least connections算法需绑定worker进程到独立物理核以避免缓存失效和锁争用：设worker_processes为物理核总数，启用worker_cpu_affinity硬绑定，配合ulimit、multi_accept、keepalive及numa隔离优化。
Least Connections 算法本身不直接影响 CPU 绑定，但它对 worker 进程的负载分布敏感——如果 worker 没绑定到专属物理核，连接统计、锁竞争和共享内存访问就会成为瓶颈。优化核心是让每个 worker 稳定运行在独立物理核上，使 least_conn 的计数器更新、上游连接状态同步等操作尽可能本地化。
worker_processes 必须匹配物理核数，而非逻辑核或 auto
least_conn 依赖每个 worker 维护自己的连接计数（通过共享内存同步），但频繁跨核更新会引发缓存行失效和锁争用。因此：
- 用 lscpu | grep "Core(s) per socket" 查清物理核心总数，再乘以 CPU 插槽数（如双路 16 核 → 总 32 物理核）
- 设 worker_processes 32（不是 64，超线程对 least_conn 场景无收益，反而加剧 L2 缓存冲突）
- 避免
worker_processes auto，它可能把进程分到超线程副核或跨 NUMA 节点
必须启用 worker_cpu_affinity 实现一对一硬绑定
least_conn 的 upstream 连接状态更新、shared memory slab 分配都依赖 CPU 缓存局部性。未绑定时，worker 迁移会导致 SSL 会话缓存、upstream 共享锁频繁失效：
- 推荐写法：worker_cpu_affinity auto（Nginx ≥1.9.10），自动避开超线程对，优先分配物理核
- NUMA 架构下需手动拆分：如双路服务器，Node 0 含 CPU 0–15，则用 worker_cpu_affinity 0000000000000001 ...（共 16 组 16 位掩码）限定在 Node 0
- 验证方式：ps -eo pid,psr,comm | grep 'nginx: worker'，输出中每个 worker 的 PSR 值应唯一且固定
配套调优确保 least_conn 高效运转
算法效果受限于底层资源供给。若系统级限制没放开，least_conn 会因连接建立失败或排队延迟而失真：
-
worker_rlimit_nofile 至少设为
worker_processes × worker_connections（如 32×4096 = 131072） - 系统级 ulimit：/etc/security/limits.conf 中为 nginx 用户设
nofile 200000 - 关闭 accept_mutex（Nginx ≥1.11.3 默认关闭），启用 multi_accept on，让单次事件循环尽可能多地接收新连接，减少 least_conn 判定时的“滞后窗口”
- upstream 块中启用 keepalive 200 并配 proxy_http_version 1.1，避免短连接反复触发 least_conn 决策开销
NUMA 节点隔离进一步降低跨节点延迟
least_conn 的 shared memory 区域（如 upstream zone）若被跨 NUMA 访问，计数器更新延迟可能达数百纳秒，导致多个 worker 对同一 upstream server 的连接数判断不同步：
- 用 numactl --hardware 查清节点拓扑（如 Node 0: CPU 0–15, Mem 64GB）
- 启动 Nginx 时用 numactl 限定： numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx
- 验证：numastat -p $(pgrep nginx)，local_node 应 >95%，foreign 接近 0
