maxpoolsize设100会因连接数超载导致mongodb变慢：4个worker×100=400连接压垮单线程mongos，%sy cpu飙升至40%+，上下文切换激增、延迟升高；合理值应按峰值qps×p95延迟÷1000×1.2计算，并协同minpoolsize、maxidletimems等配置调优。
maxPoolSize设100为什么会让MongoDB变慢
不是连接越多越快，而是每个连接都要占用mongos或mongod的一个线程（或协程）。当maxPoolSize设为100，又跑在cluster模式的4个worker里，实际就向mongos发了400个连接——而mongos路由分发是单线程的，连接数超过后端mongod节点数 × 2后，吞吐基本不涨，纯增上下文切换开销。
实测中，%sy（系统态CPU）会从15%飙到40%以上，top里看到大量mongos线程在等待调度，请求延迟反而升高。
- Node.js驱动的
maxPoolSize是每个MongoClient实例的上限，不是全局共享值 - 默认
maxPoolSize: 100只适合单进程、低QPS、且明确压测过mongos连接承载能力的场景 - 没配
minPoolSize和maxIdleTimeMS时，空闲连接永不释放，netstat -an | grep :27017 | wc -l只会涨不会跌
怎么算出合理的maxPoolSize值
拍脑袋设数字等于埋雷。真实值得从你的流量模型里推：峰值QPS × p95延迟（毫秒）÷ 1000，再上浮10%～20%作缓冲。
例如：监控显示峰值QPS=300，事务p95=200ms → 理论需60个并发连接 → maxPoolSize: 70较稳妥。若用PM2起3个worker，那就得把单实例值降到25左右，避免总连接数冲破mongos的maxIncomingConnections硬限。
- 中小业务（QPS maxPoolSize: 10~20，配
minPoolSize: 3~5 - 高吞吐聚合场景（含大量
$lookup）：可放宽到maxPoolSize: 30，但必须同步设socketTimeoutMS: 30000 - 绝对不要让
maxPoolSize × worker数> mongos的maxIncomingConnections × 0.8
事务场景下maxPoolSize错配的连锁反应
事务会独占连接，直到commitTransaction()或显式调用session.endSession()。如果maxPoolSize设得太大，而事务又因慢查询、缺失索引或网络卡顿迟迟不结束，连接池就会被“钉死”——新请求排队等，触发Timeout waiting for a pooled item或waitQueueTimeoutMS超时。
更糟的是，在分片集群里，一个跨shard事务可能同时占用多个mongos连接，放大乘数效应。此时盲目拉高maxPoolSize只会加速打满后端节点。
- 估算依据应是「并发活跃事务数」，而非总QPS；可用
db.currentOp({ secs_running: { $gt: 1 } })查真实堆积 - 务必设
waitQueueTimeoutMS: 3000–5000，比P99事务耗时略长，让失败快速暴露 - 手动管理事务时，
try/finally包裹session.endSession()是底线，不能依赖GC
最容易被忽略的配置协同点
单改maxPoolSize没用，它必须和minPoolSize、maxIdleTimeMS、socketTimeoutMS一起调。比如minPoolSize太小（如0），冷启动时前几十个请求要重建连接，P99延迟跳升80ms；maxIdleTimeMS不设（默认0），空闲连接永远不退，连接池实质变成“只进不出”。
还有个隐形陷阱：connectTimeoutMS和socketTimeoutMS必须小于上游Nginx或LB的超时设置，否则会出现“连接已断但请求还在等”的悬挂状态，进一步拖慢池子回收节奏。
-
minPoolSize建议不低于5，冷启期并发数低时也能撑住 -
maxIdleTimeMS设60000（60秒）是多数场景的安全值，太短（如10秒）会导致频繁建连 - 所有超时参数（
connectTimeoutMS、socketTimeoutMS、serverSelectionTimeoutMS）必须显式声明，别信默认值
