maxConns 在 MongoDB 3.4+ 中已废弃且完全不生效；真正有效的是 net.maxIncomingConnections，且必须同步调高系统 ulimit -n 才能生效。
maxConns 在 MongoDB 副本集中完全不生效，改它没用；真正该设的是 net.maxIncomingConnections，且必须配合系统级 ulimit -n 调整才起作用。
为什么 maxConns 改了也无效
maxConns 是 MongoDB 3.2 及更早版本的遗留参数，从 3.4 开始被官方标记为 deprecated，启动时会静默忽略。你在 /etc/mongod.conf 里写 maxConns: 500，db.serverStatus().connections 返回的 current 依然可能飙到 2000+。这不是配置漏了，是它根本不再参与连接控制逻辑。
常见误判现象：
- 日志里找不到任何
maxConns相关 warning 或 error - 执行
db.adminCommand({setParameter: 1, maxConns: 500})报错或无响应 - 副本集节点突然拒绝新连接，但
available字段显示还有几百空余
正确设置 net.maxIncomingConnections
这是当前（2026 年主流版本 6.0 / 7.0）唯一有效的服务端总连接闸门。它作用于整个 mongod 进程，不区分用户、IP 或读写角色。
配置要点：
- 必须写在
net:区块下，不能塞进setParameter:里 - 值不是越大越好：4 核 8GB 机器设 2000 比设 10000 更稳，高连接数会加剧锁竞争和内存碎片
- 修改后必须
sudo systemctl restart mongod，reload不生效 - 验证方式：连上后运行
db.serverStatus().connections，观察available是否接近你设的值（注意：available = maxIncomingConnections - current）
示例配置片段：
net: port: 27017 bindIp: 127.0.0.1,::1 maxIncomingConnections: 2000
系统层 ulimit 必须同步调高
MongoDB 每个连接占用一个文件描述符（fd），而 mongod 进程启动时继承 shell 的 ulimit -n 值。如果系统软限只有 1024，你配了 2000 也卡死在 1000 左右。
操作步骤：
- 临时生效（仅当前 session）：
ulimit -n 65536 - 永久生效需两处修改：
– 编辑/etc/security/limits.conf，添加：mongod soft nofile 65536mongod hard nofile 65536
– 若用 systemd（绝大多数现代发行版），还需在/etc/systemd/system/mongod.service.d/override.conf中加：[Service]<br>LimitNOFILE=65536
- 改完 reload systemd 配置：
sudo systemctl daemon-reload，再重启 mongod
验证命令：cat /proc/$(pidof mongod)/limits | grep "Max open files"
副本集场景下真正该控的是客户端连接池
副本集各节点独立管理连接，没有统一调度。靠服务端硬限只能兜底，治标不治本。实际压垮节点的，往往是应用侧未收敛的连接行为。
关键实践：
- Node.js 驱动默认
maxPoolSize: 100，别留默认值，按服务真实并发设为 20～50 - 避免所有服务直连
secondary却不设readPreference=secondary，否则读流量全堆在一个节点上 - 检查防火墙或 HAProxy 的
timeout idle，若短于 MongoDB 实际处理耗时，会引发大量重连风暴 - 监控重点应是
db.serverStatus().connections.current+os.network.numRequests组合，而不是盯着一个失效的maxConns
连接泄漏比上限设低更危险——即使你设了 2000，若应用每次请求都 new MongoClient 却不 close，几分钟就打满。
