maxconns 自 mongodb 3.4 起已被弃用，实际连接上限由操作系统 ulimit -n 决定；需调高 nofile 限制并配置 maxincomingconnections（3.6+）或驱动端 maxpoolsize。

maxConns 参数在副本集中基本无效

从 MongoDB 3.4 开始，maxConns 已被官方弃用，即使你在 mongod.conf 中显式设置 maxConns: 2000，启动时也不会生效，db.serverStatus().connections 显示的 available 值仍由操作系统限制主导。日志里不会报错，也不会警告，只是静默忽略。你看到的“819”连接上限，几乎总是 Linux 默认 ulimit -n（1024）减去系统保留 fd 后的结果，而非 MongoDB 自身控制。

真正要调的是操作系统文件描述符限制

每个 TCP 连接占用一个文件描述符（fd），mongod 进程能打开多少连接，直接受限于它启动时继承的 nofile 上限。常见错误现象是：副本集某节点突然拒绝新连接，db.serverStatus().connections 显示 current 接近 available，但查不到 maxConns 相关日志。

• 临时验证当前限制：ulimit -n；查看 mongod 进程实际限制：cat /proc/$(pidof mongod)/limits | grep "Max open files"
• 永久修改需两步：  • 编辑 /etc/security/limits.conf，追加：
  mongod soft nofile 65536
mongod hard nofile 65536
   • 若使用 systemd（绝大多数现代发行版），还需创建 /etc/systemd/system/mongod.service.d/override.conf，写入：
  [Service]
LimitNOFILE=65536
• 改完必须重启 mongod 服务，且确保 shell 启动用户属于 mongod 组，否则 limits 不生效

副本集场景下更关键的是客户端 maxPoolSize

副本集没有“统一连接调度”，每个节点独立维护连接池，而驱动（如 Node.js）默认为每个节点开一个池。三节点副本集 + 默认 maxPoolSize: 100，光监控连接就占掉 6 个（每节点 2 个），实际可用连接远少于 100。若应用启用 readPreference=secondaryPreferred，驱动会为所有 secondary 预建连接池，总连接数可能达 3×maxPoolSize + 6。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 别只看 QPS，要算连接持有时间：maxPoolSize ≈ QPS × 平均响应时间（秒）× 节点数 × 1.3（留 30% 缓冲）
• 连接字符串中直接设参数更可靠：mongodb://host1,host2,host3/?maxPoolSize=200
• 避免在代码里重复 new MongoClient()，每个实例都带独立池；应全局复用单个 client
• 监控重点不是 maxConns，而是 db.serverStatus().connections.current 的 95 分位峰值

云环境或新版 MongoDB 应优先用 maxIncomingConnections

如果你用的是 MongoDB 3.6+ 或云托管服务（如 Atlas、阿里云 MongoDB），maxConns 完全失效，正确参数是 maxIncomingConnections，它在 setParameter 或 net 段下配置：

• 配置文件方式（推荐）：
  net:
maxIncomingConnections: 10000
• 命令行方式：mongod --maxIncomingConnections 10000
• 注意：该值仍受操作系统 nofile 限制制约，若 ulimit -n 只有 1024，设再大也无用
• Atlas 等托管服务中，该值按规格自动分配（如 m40 实例为 6000），控制台可动态提升，但仅限临时应对大促

真正难搞的从来不是配哪个参数，而是确认当前瓶颈到底在驱动池、OS fd、还是网络中间件的 idle timeout —— 三者混在一起时，maxConns 这种过时字段只会把你带偏方向。