[SERVER-32848] Recover performance regressions due to timestamps Created: 23/Jan/18 Updated: 24/Jul/18 Resolved: 20/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Alexander Gorrod | Assignee: | Alexander Gorrod |
| Resolution: | Done | Votes: | 0 |
| Labels: | nonnyc, storage-engines | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Sprint: | Storage Non-NYC 2018-05-21 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
A number of replica set performance tests showed regressions with the MongoDB 3.6 release due to enabling read concern majority. Some of these regressions were due to WiredTiger being required to keep more content in cache, and the implementation of an external transaction ID manager (timestamps). We need to re-run those workloads and make changes to return performance to previous levels where it's practical. |
| Comments |
| Comment by Alexander Gorrod [ 20/May/18 ] |
|
I'm going to close out this ticket since it doesn't describe a problem with the code that can be fixed. |
| Comment by Eric Milkie [ 20/Apr/18 ] |
|
Asya: the priority here is to investigate anything that seems like potential blockers for 4.0. The others can be turned into re-baselining our current perf levels. |
| Comment by Asya Kamsky [ 06/Apr/18 ] |
|
Would like to discuss at next Needs Triage meeting. |