Amazon Linux上MongoDB 3.4最大并发连接数仅为4077的问题排查

结合你的环境（t2.micro实例 + Amazon Linux 2 + MongoDB 3.4），连接数卡壳的问题通常和进程资源限制、MongoDB自身配置、系统全局参数甚至实例硬件配额有关，咱们一步步排查解决：

1. 先确认MongoDB自身的连接数上限配置 #

MongoDB默认会根据系统资源自动计算最大连接数，但也可以手动指定更合适的值：

• 登录MongoDB Shell：mongo
• 查看当前生效的maxConnections：

  db.runCommand({getParameter: 1, maxConnections: 1})
  

• 如果当前值低于你的预期，修改MongoDB配置文件（通常是/etc/mongod.conf），在net段下添加或调整：

  net:
    maxConnections: 45000  # 建议设为比ulimit -n小5000左右，留足系统文件描述符余量
  

• 重启MongoDB服务生效：sudo systemctl restart mongod

2. 确保MongoDB进程继承了正确的ulimit设置 #

很多时候用户级ulimit配置生效了，但MongoDB作为系统服务启动时没继承到，需要修改systemd配置：

• 编辑MongoDB的systemd服务文件：sudo vi /usr/lib/systemd/system/mongod.service
• 在[Service]区块内添加以下两行：

  LimitNOFILE=50000  # 和你设置的ulimit -n保持一致
  LimitNPROC=3867     # 对应你ulimit里的pending signals值
  

• 重新加载systemd配置：sudo systemctl daemon-reload
• 重启MongoDB后，验证进程实际的资源限制：

  # 先获取MongoDB进程PID
  PID=$(pgrep mongod)
  # 查看进程的文件描述符上限
  cat /proc/$PID/limits | grep "Max open files"
  

  确认输出值为50000即可。

3. 检查系统全局文件描述符限制 #

进程级的ulimit不能超过系统全局的文件描述符上限，所以需要同步调整：

• 编辑/etc/sysctl.conf，添加或修改：

  fs.file-max = 100000  # 必须大于进程级的50000
  

• 让配置立即生效：sudo sysctl -p
• 验证结果：sysctl fs.file-max

4. 考虑t2.micro的硬件资源瓶颈 #

t2.micro只有1GB内存，而MongoDB每个连接大约会占用1MB左右的内存，4077个连接已经接近实例的内存上限。MongoDB会主动限制连接数来避免内存耗尽导致崩溃：

• 如果需要更高并发，建议升级到内存更大的实例（比如t2.small或t3.medium）；
• 同时优化应用侧的连接池配置：减少空闲连接时长、设置合理的连接超时、控制连接池大小。

5. 验证最终效果 #

重启MongoDB后，在Shell里查看当前连接状态：

db.serverStatus().connections

输出会显示current（当前活跃连接数）和available（剩余可用连接数），两者之和就是实际生效的最大连接数。

内容的提问来源于stack exchange，提问作者Master Po