mongos连接池默认参数易打满，因minConnsPerHost=0、maxConnsPerHost=100，高并发时触发排队或连接风暴；需确保shard端net.maxIncomingConnections≥mongos侧maxConnsPerHost，推荐min=10、max=200以平衡冷启延迟与资源开销。
mongos连接池默认参数为什么容易打满
mongos对每个shard维护独立连接池，但默认minConnsPerHost是0、maxConnsPerHost是100，高并发写入时极易触发连接排队或新建连接风暴。尤其当业务线程数远超连接池上限，或shard端net.maxIncomingConnections设得过小（比如默认64），就会出现大量connection refused by peer错误，实际表现为路由层延迟抖动、偶发timeout。
- 用
db.adminCommand({ "connPoolStats": 1 })查host字段下各shard的inUse和available值，若长期inUse == maxConnsPerHost，说明池已饱和 - 检查shard节点配置里的
net.maxIncomingConnections，必须≥ mongos侧设的maxConnsPerHost，否则mongos建连请求会被直接拒绝 - 避免把
maxConnectionPoolSize和maxConnectionLifeTime都设得过高（如双500），会挤占系统文件描述符，且mongos自身有硬限制（通常65535）
怎么配min/maxConnsPerHost才不浪费也不卡顿
不是越大越好，关键看你的shard数量、单shard吞吐能力和网络RTT。实测中，minConnsPerHost=10能有效缓解冷启动时首请求延迟；maxConnsPerHost=200在多数中等规模集群（≤20 shard）下足够覆盖峰值，再往上收益递减，反而增加上下文切换开销。
- 若shard部署在同可用区（RTT maxConnsPerHost设150–200较稳妥
- 若跨AZ（RTT 5–10ms），建议降到100–120，防止连接堆积放大网络延迟影响
-
minConnsPerHost不要设0——每次新连接都要走三次握手+TLS协商，比复用现有连接慢3–5倍
Java驱动里mongos连接池和Netty线程怎么协同
Java驱动底层用Netty做IO，bulkWrite本身不占业务线程，但每个并发请求会争抢Netty event loop线程。如果业务线程池远大于Netty线程数，请求就在event loop队列里排队，看起来像mongos卡顿，其实是IO线程瓶颈。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 查
MongoClientSettings.ioThreadPoolSize（默认Runtime.getRuntime().availableProcessors() * 2），生产环境建议设为cpu核心数 + 4 - 业务写入线程池大小 ≤
ioThreadPoolSize × 2，例如IO线程8个，业务线程最多16个 - 禁用
maxConnectionLifeTime（设0），让连接自然复用，避免频繁重连带来的DNS解析和TLS握手开销
连接池调优后还要防DNS拖慢路由决策
即使连接池参数全调优，第一次路由仍可能卡在DNS解析上——mongos启动后首次查询慢、偶发超时，八成是getaddrinfo()在等AAAA记录回退。IPv6 DNS慢或返回无效AAAA会拖慢单次路由决策1–3秒，完全掩盖连接池优化效果。
- 启动mongos时加
--bind_ip 127.0.0.1，并在配置文件中用IP直连所有shard（而非域名），彻底绕过DNS - 若必须用域名，确保DNS服务器A记录响应/etc/gai.conf加
precedence ::ffff:0:0/96 100禁用IPv6优先 - 用
strace -e trace=getaddrinfo,connect -p $(pgrep mongos)确认是否真卡在解析环节
连接池参数只是表象，真正卡住mongos路由的，往往是DNS解析、跨区网络RTT、或shard端连接数限制这些底层约束。调参前先抓connPoolStats和strace，别让优化变成盲目堆数字。
