least_conn算法本身开销低，但节点过多、keepalive配置不当、高频主动健康检查及滥用max_conns会增加CPU、内存与锁竞争；应精简调度范围、合理设keepalive 16–32、主动检查间隔≥3s、仅异构节点配max_conns，并通过stub_status和nginx -T验证实际效果。
least_conn 本身不直接消耗显著内存或引发高锁竞争，它的开销主要来自连接数统计、节点筛选和健康状态维护。真正影响内存与锁效率的，是配置方式和配套机制是否合理。
精简连接数统计范围
默认情况下，Nginx 会为每个 upstream server 维护一个连接计数器，并在每次请求进入/退出时原子增减。若后端节点过多（如上百台），计数器更新和比较过程会轻微增加 CPU 和缓存行争用。
- 只对真实参与调度的节点启用 least_conn：避免把已下线、仅作 backup 的机器写进同一 upstream 块
- 拆分大规模集群：比如将 120 台推理节点按 GPU 型号或机房划分为多个 upstream（ai-gpu-a、ai-gpu-b），每组控制在 20–40 节点内
- 禁用无意义的 keepalive 复用：upstream 中 keepalive 值设为 0 或过大会导致空闲连接长期计入统计，徒增计数器“噪音”；推荐值为 16–32（单 worker）
减少健康检查带来的锁压力
被动健康检查（proxy_next_upstream）本身不加锁，但主动健康检查（health_check 指令）由 master 进程统一调度，高频探测可能引发 worker 间状态同步开销。
- 主动检查间隔不低于 3 秒，失败阈值设为 fails=2 而非 1，避免瞬时抖动触发频繁状态变更
- 检查路径务必独立、轻量：使用专用 /health 端点，绕过鉴权、日志、中间件，响应体小于 100 字节
- 若用开源版 Nginx 且无 health_check 模块，就依赖 proxy_next_upstream + max_fails，它基于请求上下文做局部判断，无全局锁
规避 max_conns 引发的额外判断开销
max_conns 是软性容量门限，每次选节点前都要检查是否已达上限。虽然单次判断极快，但在超高并发（QPS > 5w）下，重复判断会叠加微小延迟。
- 只对能力差异明显的节点设 max_conns，同构集群可省略，靠连接数自然分流
- 避免为每个 server 都配 slow_start：该参数需维护时间滑动窗口，冷启动期间会额外记录权重变化轨迹
- 不混用 ip_hash / hash：这些策略与 least_conn 互斥，Nginx 在解析时会报错并中止加载，看似无关，实则影响配置热更稳定性
监控真实内存与锁表现
不要只看配置是否“看起来高效”，要验证运行态行为：
- 用 stub_status 查看 active connections 分布，若某节点长期为 0 而其他节点持续 >80%，说明健康检查未生效或 max_conns 设置过严
- 通过 nginx -T | grep -c "least_conn" 确认只在必要 upstream 中启用，避免全局污染
- 观察 worker 进程 RSS 内存：稳定在 30–60MB 属正常；若单个 worker 超过 120MB，重点排查是否 keepalive 过大或后端响应头带 Connection: close 导致连接池失效、反复建连
