MongoDB Sharding架构下连接数很容易达到很高，这里连接数分为几个概念： tcp 连接数 netstat可以统计的，一般这个是最高.如果mongod/mongos在同一台服务器，更明显。 参考命令：
netstat -ant|awk ‘{print $5}’ |awk -F: ‘{print $1}’|sort |uniq -c|sort -rn mongos/mongod
连接数 mongostat/db.serverStatus()/connPoolStats
可统计。
连接数多高算高呢？
这要看连接到mongodb集群应用服务器实例数、qps(增删改查)等判断。 应用服务器单台，如果qps<100, ，mongos连接数超过2000，肯定是高了。这一般是由于连接池配置不合理导致。 mongod/mongos 默认最大连接数maxConns=20000，2.4版本及以前版本最大不能超过这个数值，2.6版本（开发版2.5版本）取消这个限制。 相关链接http://nosqldb.org/topic/50ca8a50ee680fee790001f2
什么原因导致连接数过高
-
连接池配置不合理 分片情况下，现象是tcp 连接数过高（如达到20000），mongos连接数过高（如超过10000） java为例，connectionsPerHost 不宜配置过大，官方默认值由原来10改成100了，而且有默认5倍的乘数(threadsAllowedToBlockForConnectionMultiplier)，一般20~50就可以了。
-
应用服务器实例过多
我们遇到的场景，当连接到mongos的应用服务器（如Tomcat实例数量）过百，甚至达到近200台时，tcp连接数超高，达到15000以 上，查看mongod对应端口连接数高达8000多，mongos 2000多。此时ops（query,insert,update,delete）低于200每秒,。定期重启（如一周一次）mongos可适当缓解该问 题。
- mongodb本身的原因 表现为mongos连接数不高（如1000+），mongod连接数比较高（如8000+）。
如何解决 总结一下，连接数高分为几个场景： 应用服务器实例过多，可统计每个实例建立的连接数，适当调低连接池参数。 mongos连接数高，这种就是配置的问题，更改连接池参数。 mongos连接数不高，mongod连接数比较高，如超过5000，如果连接池配置合理还比较高的话，尝试启用releaseConnectionsAfterResponse参数（2.2.4版本以上），该参数为 隐藏参数releaseConnectionsAfterResponse
mongos> use admin
switched to db admin
mongos> db.runCommand({ setParameter : 1, releaseConnectionsAfterResponse : true })
{ "was" : false, "ok" : 1 }
或者
shell> mongos --setParameter "releaseConnectionsAfterResponse=true" --configdb ...
该参数注意事项： 写操作需要立即调用getLastError （w=1，即安全写模式）,w=2（等待从库写确认）的时候可能会有些错误。 升级过后，或者重启mongos进程后，需要重新设置该参数，该参数只对单个mongos生效。 启用releaseConnectionsAfterResponse 参数，tcp 连接数明显降低到比较稳定数目。几个小时，tcp连接数从8000多降到4000多，效果不错。
- releaseConnectionsAfterResponse 参数原理
通常，对于每个mongos->mongod连接是单独缓存的，并且该连接不能重复使用，即使该连接是空闲时也是如此，一直到连接关闭连接回 到连接池中才能再使用；releaseConnectionsAfterResponse 参数启用后，mongos->mongod之间的连接在完成一个读操作或者安全写操作后能够重复使用（把连接放到连接池中而不是缓存，即更早的回归 到连接池中），releaseConnectionsAfterResponse参数简单讲就是mongos->mongod的连接更早的回到连接 池中，这样就不会开太多的连接了，从而减少连接数。 Create a new serverParameter for mongos, “releaseConnectionsAfterResponse,” which enables returning ShardConnections from the per-socket pool to the global pool after each read operation. This should reduce the total number of outgoing mongos connections to each shard. the option allows better use of the connection pool, it doesn’t invalidate the connections in the pool. Normally, mongos->mongod connections for insert/update/delete/query are cached individually for each incoming connection, and can’t be re-used until the incoming connection is closed, even if they are idle and there are other active incoming connections. What the releaseConnectionsAfterResponse option does is allow the mongos->mongod connection to be re-used (returned to the pool) after any read op (including getLastError(), so after safe writes as well). It shouldn’t have a significant performance impact - the connection isn’t destroyed, it’s just returned from the incoming connection cache to the shared pool early.
代码： https://github.com/mongodb/mongo/commit/706459a8af0b278609d70e7122595243df6aeee8 https://github.com/mongodb/mongo/commit/74323d671a216c8c87fcb295ed743f830d5212ee https://github.com/mongodb/mongo/commit/5d5fe49dfb5f452832b9d44fddbfb2a4e8b42f2a
=============== - connPoolTimeout设置
（该参数不在官方没有） 效果
mongos> db.runCommand({ setParameter : 1, connPoolTimeout : 900 })
{ "was" : 1800, "ok" : 1 }
初步测试，效果不明显。
- releaseConnections
计划添加个命令releaseConnections，从mongod运行，减少复制集连接数