MongoDB默认的最大连接数是65536，看起来很大，但在生产环境中，连接数暴涨导致服务异常的案例并不少见。典型表现是应用日志中频繁出现"connection refused"或"too many connections are open"，严重时整个数据库响应变慢甚至拒绝服务。要彻底解决这个问题，不能只靠调大上限，更重要的是弄清楚连接到底从哪里来、为什么没有被释放。
一、先搞清楚连接数的现状
排查的第一步永远是看清现状。登录到MongoDB实例，执行db.serverStatus().connections可以拿到三个关键指标：current表示当前已建立的连接数，available表示剩余可用的连接数，totalCreated表示服务启动以来累计创建过的连接数。
// 查看连接概况
db.serverStatus().connections
// 输出示例：{ current : 812, available : 64724, totalCreated : 392812 }
如果current数值持续攀升且不见回落，说明连接在泄漏或者有源源不断的新建连接。此时可以进一步执行db.currentOp(true)配合aggregate查看每个连接的来源IP和持续时长，统计出到底是哪些机器、哪些进程占用了连接。命令行工具mongostat也能直观显示连接数变化趋势。
一个实用的排查技巧是按客户端IP分组统计连接数。如果某个IP占了几千个连接，而那台机器上只部署了几个应用实例，那基本可以断定是连接池配置过大或者连接泄漏。
二、连接数过多的常见原因
1. 驱动连接池配置过大
这是最常见的原因。很多ORM或框架默认给每个客户端实例配置了较大的连接池，比如Node.js的mongoose默认maxPoolSize是100。如果应用部署了50个容器实例，理论上最大连接数就是5000，再加上监控、备份脚本、运维工具的连接，很容易触顶。计算公式很简单：单实例连接池大小乘以实例数量，必须小于服务端maxConnections减去预留的运维连接。
2. 连接未正确释放
使用原生驱动时，如果每次请求都调用mongo.Connect()新建客户端却不复用，或者会话、游标没有关闭，连接就会不断堆积。特别是在Serverless、函数计算场景下，每次函数执行都创建新连接，冷启动频繁时连接数会瞬间飙升。
3. 监控和探活脚本滥用
有些团队用crontab每分钟执行一次健康检查脚本，每次都新建连接再退出。单个脚本看似无害，但如果部署在多台机器上、检查频率又高，短连接累积起来的数量相当可观。此外，负载均衡器或K8s的liveness probe如果配置了TCP直连检测，也会不断产生短连接。
三、具体的处理方案
1. 合理收紧客户端连接池
连接池并不是越大越好。对大多数OLTP场景来说，每个应用实例5到20个连接已经足够支撑高并发，因为MongoDB驱动的连接池是非阻塞复用模式，请求会在池中排队而不是阻塞等待。以下是Node.js和Go的配置示例：
// mongoose 连接配置
mongoose.connect(uri, {
maxPoolSize: 20, // 最大连接数
minPoolSize: 5, // 最小保持的连接数
maxIdleTimeMS: 60000, // 空闲连接60秒后回收
serverSelectionTimeoutMS: 5000
});
// Go驱动连接配置
opts := options.Client().
ApplyURI(uri).
SetMaxPoolSize(20).
SetMinPoolSize(5).
SetMaxConnIdleTime(60 * time.Second)
client, err := mongo.Connect(ctx, opts)
配置的关键点在于让池大小与实例数量联动。比较稳妥的做法是：服务端maxConnections设为5000到10000，预留10%给运维操作，剩余额度除以应用实例数，得到每个实例的池上限。
2. 保证客户端全局单例复用
无论用什么语言，MongoClient都应该在进程内只创建一次，所有请求共享同一个客户端实例。以Go为例，把client初始化放在main函数中，通过依赖注入传递，而不是在每个handler里重新连接。短生命周期场景如云函数，则应把client缓存在全局变量中，利用函数实例的复用机制避免重复建连。
3. 服务端限制与防护
可以通过启动参数--maxConns或在配置文件中设置上限，防止连接无限增长把内存拖垮。同时在网络层做防护：只允许应用网段访问27017端口，配合防火墙规则拦截异常来源。如果使用的是云上的托管服务，还可以开启连接数告警，在current超过阈值80%时提前通知。
# 修改最大连接数并重启 mongod --config /etc/mongod.conf --maxConns 10000 # 配置文件方式 # net: # maxIncomingConnections: 10000
4. 排查并治理短连接
把健康检查脚本改成常驻长连接，或者降低执行频率；K8s的TCP探活尽量拉长检测间隔。对于确实需要的短连接场景，务必确保使用完毕后调用client.Disconnect()或close()释放资源。还可以在代码中通过defer语句保证异常路径下连接也能关闭。
四、长效预防机制
解决问题之后，还需要建立监控和规范防止复发。首先是接入连接数监控，把connections.current、connections.available接入Prometheus，配合Grafana面板观察趋势，设置合理的告警阈值。其次是建立配置规范，将连接池参数纳入统一的配置中心管理，禁止各团队随意调大池子。
另外建议定期做连接审计，通过db.currentOp导出连接清单，与登记的应用实例做比对，及时发现未知的连接来源。在架构层面，如果应用实例规模持续扩大，可以考虑在数据库前加一层连接代理（如mongos路由或第三方连接池中间件），把海量客户端连接收敛到代理层，数据库只需要面对少量稳定的长连接。
总结来说，MongoDB连接数过多本质上是一个资源管理问题：源头控制好每个客户端的连接需求，中间确保连接被正确复用和释放，服务端设置合理上限并做好监控，三管齐下才能让连接数长期稳定在健康区间。
MongoDB连接数maxConnections连接池修改时间：2026-09-08 15:29:12