[SERVER-53853] Large buildup of mongos to mongod connections and low performance with secondaryPreferred reads Created: 16/Jan/21 Updated: 08/Jan/24 Resolved: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.2.0, 4.2.11 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Amirsaman Memaripour |
| Resolution: | Gone away | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||
| Steps To Reproduce: | Run this workload against a single-shard cluster
|
||||||||||||||||||
| Sprint: | Service Arch 2021-02-08, Service Arch 2021-02-22, Service Arch 2021-03-08, Service Arch 2021-03-22, Service Arch 2021-04-05, Service Arch 2021-04-19, Service Arch 2021-05-03 | ||||||||||||||||||
| Participants: | |||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||
| Description |
|
Test consists of 500 threads doing secondaryPreferred reads as fast as possible against a single shard cluster. In the chart below the queries before A are from the primary for reference, after A are secondaryPreferred.
|
| Comments |
| Comment by Matthew Tretin (Inactive) [ 23/Apr/21 ] |
|
We believe this issue was addressed with https://jira.mongodb.org/browse/SERVER-54278. Thanks everyone! |
| Comment by Bruce Lucas (Inactive) [ 20/Jan/21 ] |
|
There's another report in |
| Comment by Bruce Lucas (Inactive) [ 19/Jan/21 ] |
|
This issue affects 4.2.0 and 4.2.11, but does not seem to affect 4.0.22 nor 4.4.3. |
| Comment by Bruce Lucas (Inactive) [ 17/Jan/21 ] |
|
While doing some more experiments I found that this issue does not always occur - sometimes the secondary reads are evenly distributed between the secondaries and no buildup of connections occurs. I guess this is the expected behavior? However it seemed to reproduce reliably when running the above (both mongo client and single-shard cluster) all on a single desktop machine with 24 cpus. Also noticed the following:
During the period A-B for example
|