Nginx Least Connections 算法如何在多核心 CPU 服务器上进行 worker 绑定优化

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 维护自己的连接计数（通过共享内存同步），但频繁跨核更新会引发缓存行失效和锁争用。因此：

1. 用 lscpu | grep "Core(s) per socket" 查清物理核心总数，再乘以 CPU 插槽数（如双路 16 核 → 总 32 物理核）
2. 设 worker_processes 32（不是 64，超线程对 least_conn 场景无收益，反而加剧 L2 缓存冲突）
3. 避免 worker_processes auto，它可能把进程分到超线程副核或跨 NUMA 节点

必须启用 worker_cpu_affinity 实现一对一硬绑定

least_conn 的 upstream 连接状态更新、shared memory slab 分配都依赖 CPU 缓存局部性。未绑定时，worker 迁移会导致 SSL 会话缓存、upstream 共享锁频繁失效：

1. 推荐写法：worker_cpu_affinity auto（Nginx ≥1.9.10），自动避开超线程对，优先分配物理核
2. NUMA 架构下需手动拆分：如双路服务器，Node 0 含 CPU 0–15，则用 worker_cpu_affinity 0000000000000001 ...（共 16 组 16 位掩码）限定在 Node 0
3. 验证方式：ps -eo pid,psr,comm | grep 'nginx: worker'，输出中每个 worker 的 PSR 值应唯一且固定

配套调优确保 least_conn 高效运转

算法效果受限于底层资源供给。若系统级限制没放开，least_conn 会因连接建立失败或排队延迟而失真：

1. worker_rlimit_nofile 至少设为 worker_processes × worker_connections（如 32×4096 = 131072）
2. 系统级 ulimit：/etc/security/limits.conf 中为 nginx 用户设 nofile 200000
3. 关闭 accept_mutex（Nginx ≥1.11.3 默认关闭），启用 multi_accept on，让单次事件循环尽可能多地接收新连接，减少 least_conn 判定时的“滞后窗口”
4. upstream 块中启用 keepalive 200 并配 proxy_http_version 1.1，避免短连接反复触发 least_conn 决策开销

NUMA 节点隔离进一步降低跨节点延迟

least_conn 的 shared memory 区域（如 upstream zone）若被跨 NUMA 访问，计数器更新延迟可能达数百纳秒，导致多个 worker 对同一 upstream server 的连接数判断不同步：

1. 用 numactl --hardware 查清节点拓扑（如 Node 0: CPU 0–15, Mem 64GB）
2. 启动 Nginx 时用 numactl 限定： numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx
3. 验证：numastat -p $(pgrep nginx)，local_node 应 >95%，foreign 接近 0