The DBConnectionPool (legacy connection pool that backs dbclient, used for write operations through 3.5.x) has hard-to-understand and occasionally problematic growth semantics.

Our documentation for the knob that controls this pool is correct:

Set the maximum size of the connection pools for outgoing connections to other mongod instances. The size of a pool does not prevent the creation of additional connections, but does prevent a connection pool from retaining connections in excess of the value of connPoolMaxConnsPerHost.

However, it does not explain that connections retained in the pool will remain open in the pool forever, leading to a steady growth in long-lived outgoing server connections, then a plateau once the max pool size is reached, even when there is no load on the system.

We could do the following things to improve DBConnectionPool's semantics and offer more control over its growth:

• add a "MaxOpenConnections" option that would cap the number of connections that are simultaneously created (not just retained) by DBConnectionPool. For backwards compatibility this would default to infinity.

• add an "IdleHostTimeoutMS" option, so that DBConnectionPool dumps its connections to a host after this amount of time spent idle, instead of keeping them open forever. For backwards compatibility this would default to "no timeout."

• strongly suggest that customers with large clusters or many mongos set the connPoolMaxConnsPerHost and connPoolMaxShardedConnsPerHost parameters to some number that is much smaller than the default of 200.