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版本）取消這個限制。
相關連結

什麼原因導致連線數過高

• 連線池配置不合理
  分片情況下，現象是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.

===============
- connPoolTimeout設定

（該引數不在官方沒有）
效果

mongos> db.runCommand({ setParameter :1, connPoolTimeout :900}){"was":1800,"ok":1}

初步測試，效果不明顯。

• releaseConnections

計劃添加個命令releaseConnections，從mongod執行，減少複製集連線數。