本质是应用侧客户端连接池失控：java驱动默认connectionsperhost=100×multiplier=5，单实例建500连接，20台服务器即压满mongos；需调优驱动参数、启用空闲回收，并用netstat/mongostat/db.serverstatus三步定位瓶颈层。
mongos 连接数高，本质是客户端连接池没管住
分片集群里 mongos 连接数飙升，90% 以上不是 mongos 本身扛不住，而是应用侧每个实例都按默认值开了一大堆连接，又不复用、不释放。Java 驱动默认 connectionsPerHost 是 100，再乘以 threadsAllowedToBlockForConnectionMultiplier=5，单实例轻松建出 500 个连接到同一个 mongos。如果部署了 20 台应用服务器，光这一项就压满 mongos 的连接池。
实操建议：
- 把
connectionsPerHost调到20~50，别碰默认 100；threadsAllowedToBlockForConnectionMultiplier改成2或3，避免线程排队时疯狂占连接 - 确认驱动版本是否支持连接空闲回收：4.x+ Java 驱动默认启用
maxConnectionLifeTimeMS和maxConnectionIdleTimeMS，但必须显式配置才生效，例如maxConnectionIdleTimeMS=60000 - Node.js 的
mongodb驱动要注意poolSize是全局连接池大小（不是 per-host），设为10足够多数业务，别写成100
releaseConnectionsAfterResponse 参数真能减连接？
这个参数在 mongos 2.2.4+ 版本可用，作用是让 mongos 在每次响应完请求后立刻释放后端到 mongod 的连接，而不是等连接超时或复用。它只影响 mongos → mongod 这一层，对客户端到 mongos 的连接无影响。
启用前先确认：db.runCommand({ setParameter : 1, releaseConnectionsAfterResponse : true }) 返回 "ok" : 1 才算成功；该参数是运行时生效，无需重启 mongos，但只对新建立的连接起效。
注意点：
- 它对高 QPS、短平快查询收益明显，但对长事务或带
$lookup/ 跨分片聚合的请求可能增加建连开销 - 不能替代客户端连接池调优——如果客户端还在狂建连接，
mongos后端连接压下来了，前端连接照样爆 - 某些旧版驱动（如 3.4 以下 Python PyMongo）在启用了该参数后可能出现连接复用异常，建议搭配驱动升级验证
怎么快速判断连接到底卡在哪一层？
别一上来就改配置或重启。先用三组命令定位瓶颈层：
netstat -an | grep :27017 | wc -l —— 看操作系统级 TCP 连接总数，如果远高于 mongos 报告的连接数，说明存在大量 TIME_WAIT 或未关闭的 socket
mongostat --host <mongos-addr></mongos-addr> 输出里的 conn 列 —— 实时看 mongos 当前活跃连接数
db.serverStatus().connections 在 mongos shell 里执行 —— 关键看 current 和 available 差值；若 current 接近 maxIncomingConnections（默认 65536），说明已到上限
常见误判：
- 看到
mongod上连接数高，就以为是分片节点问题 —— 其实可能是某个mongos被打爆后，所有请求 fallback 到直连mongod（比如用了错误的 connection string） - 监控显示“连接数下降”，但业务仍报超时 —— 很可能是连接池被耗尽后，新请求在客户端线程池里排队，还没走到建连阶段
重启 mongos 是缓兵之计，但有前提条件
定期重启 mongos 确实能清理泄漏连接和僵死会话，尤其在长期运行、版本较老（如 3.6 或更早）的集群中效果明显。但它不是万能解，而且风险明确：
必须满足两个前提才可操作：
- 应用使用的是高可用连接串（含至少两个
mongos地址），且驱动支持自动故障转移（如 Java 4.3+、Node.js 4.0+） - 重启窗口选在低峰期，并确认没有跨
mongos的分布式事务（MongoDB 本身不支持真正的两阶段提交，但应用层模拟的事务可能依赖单一mongos的会话上下文）
线上最稳妥的做法是滚动重启：一次只重启一个 mongos 实例，观察 5 分钟无异常后再操作下一个。别图省事全量重启，否则所有连接闪断，应用重连风暴可能直接压垮剩余节点。
