[SERVER-17099] mongos seems to open double the number of connections to primary Created: 28/Jan/15 Updated: 08/Jan/24 Resolved: 24/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.6.0, 3.0.0-rc6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Asya Kamsky | Assignee: | Backlog - Service Architecture |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Operating System: | ALL |
| Participants: |
| Description |
|
While running YCSB tests with multiple mongos instances on different machines I noticed that mongos seems to be opening double the number of connections to shards than client is opening to mongos. So for example, client starts 75 threads, opens 75 connections to mongos and mongos ends up opening about 150 connections to each shard. (there are three shards and the workload are point updates and queries which are going to be evenly distributed across the shards). |
| Comments |
| Comment by Mira Carey [ 24/May/19 ] | ||||||||||||||||||||||||||||||
|
This ticket is about the behavior of the old connection pool. Since 3.6 we've been on a new pool which doesn't have different behavior/pools for the read and write path, so gone away | ||||||||||||||||||||||||||||||
| Comment by Gregory McKeon (Inactive) [ 22/May/19 ] | ||||||||||||||||||||||||||||||
|
mira.carey@mongodb.com re-raising as part of closing PM-138. | ||||||||||||||||||||||||||||||
| Comment by Randolph Tan [ 29/Jan/15 ] | ||||||||||||||||||||||||||||||
|
This is caused by how we manage our connections and how we use them differently in the write command path and query path. This can be evident when calling { shardConnPoolStats: 1 }against mongos:
As you can see, there is a separate pool for the replica set connection and the primary connection. This is a by product of the write command path using the DBClientShardResolver and never creating a replica set connection, while the normal query path actually creating a replica set connection. |