maxPoolSize过小会导致请求排队超时，因副本集每个节点有独立连接池且含监控连接，需按最坏节点数×单节点峰值设；事务并发时连接独占，须单独评估并留30%缓冲。
maxPoolSize设太小会导致请求排队超时
副本集环境下，maxPoolSize不是只看主节点流量——每个服务器（primary + secondary × N）都有独立连接池，且每个池默认最多开 maxPoolSize 个连接。更关键的是：监控线程会额外占用 2 个连接/节点（三节点副本集就是 6 个固定监控连接）。如果 maxPoolSize 设为 100，仅查 primary 就可能用掉 100 + 2 = 102 连接；若开启 readPreference=secondaryPreferred，连接数可能飙升到 300+。此时若实际并发 QPS 对应的活跃连接需求超过池上限，新请求就会卡在等待队列里，触发 waitQueueTimeoutMS 超时，抛出类似 MongoWaitQueueTimeoutException 的错误。
- 观察真实连接压力：在 MongoDB Shell 中运行
db.serverStatus().connections，重点关注current值，取生产环境高峰时段 95 分位数作为基线 - 别信默认值：Node.js 驱动默认
maxPoolSize: 100，但副本集下实际可用连接远少于这个数，尤其混合读写+监控时 - QPS ≠ 连接数：单次请求耗时越长，连接被占时间越久，所需连接数越高。公式上更接近
maxPoolSize ≈ QPS × 平均响应时间（秒），比如 200 QPS × 0.1s = 20，但这是纯查询场景；副本集+事务要再加缓冲
副本集 QPS 高时，maxPoolSize 必须覆盖所有节点潜在负载
很多团队误以为“我只读 primary，secondary 的连接池就用不上”，这是错的。只要应用代码中用了 readPreference（哪怕只是 nearest），驱动就会为每个 secondary 预建连接池，并在需要时复用。而副本集拓扑发现、心跳检测、故障转移重试都会触发对 secondary 的连接尝试——这些不是“按需创建”，而是持续保活的。所以 maxPoolSize 要按“最坏可预期节点数 × 单节点峰值连接需求”来设。
- 三节点副本集，保守按 3 ×
maxPoolSize估算总连接上限（含监控连接） - 若业务有跨机房读取 secondary 的需求，必须把对应 secondary 的网络延迟、SSL 握手开销也计入单连接平均耗时
- 云环境特别注意：AWS NLB、阿里云 SLB 默认空闲超时是 3500 秒，但
maxIdleTimeMS若设为 0，长期空闲连接会被中间设备静默断开，导致后续请求触发重连抖动
事务并发会让连接池压力翻倍，不能和普通查询混算
MongoDB 事务必须绑定单一节点（通常是 primary），且连接在事务提交或回滚前无法归还池中。这意味着 50 个并发事务 = 至少 50 个独占连接，它们不会像普通查询那样几毫秒就释放。如果你的 QPS 包含事务（比如下单、支付），这部分连接需求必须单独评估，不能和只读请求合并计算。
- 事务高峰期的
current连接数，通常比纯查询高 30%～80%，取决于事务平均持续时间 - 建议设置
maxPoolSize ≥ 峰值事务并发 × 1.3，并确保minPoolSize达到该值的 10%～20%，避免冷启动时大量事务排队建连 - 不要指望
readPreference分流事务内读操作——事务上下文里它被完全忽略，所有读写都在同一连接串行执行
连接池调大后，必须同步检查服务端资源水位
maxPoolSize 不是越大越好。MongoDB 服务端有 maxConnections 上限（Linux 默认受限于 ulimit -n），每个连接消耗约 1–5MB 内存。设成 500 时，光连接内存就可能吃掉 2GB+；若副本集节点多、客户端实例多，很容易触发 OOM 或连接拒绝。
- 先确认 MongoDB 服务端配置：
db.runCommand({getCmdLineOpts: 1})查net.maxIncomingConnections，或看/proc/sys/fs/file-max - 客户端进程也要限制：Node.js 单进程不建议超过 300，Go 可稍高但需配合
GOMAXPROCS和 GC 调优 - 真正可靠的调优方式是压测：用
mongostat或 Atlas Performance Advisor 观察network.numRequests（排队请求数），持续 > 0 就说明池不够；同时盯mem.resident和 CPU，防止资源反噬
