[SERVER-34941] Add testing to cover cases where timestamps cause cache pressure Created: 10/May/18 Updated: 29/Oct/23 Resolved: 27/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.6.4 |
| Fix Version/s: | 3.6.7, 4.0.1, 4.1.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Benety Goh |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | SWKB, nyc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Storage NYC 2018-07-30 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
During recovery oplog application we don't advance the oldest timestamp. This can pin a lot of data in the cache and we can get stuck with the cache full. |
| Comments |
| Comment by Benety Goh [ 27/Jul/18 ] |
|
Reproduction script shows that the stuck cache issue was resolved between 3.6.5 and 3.6.6. There is a reported performance regression reported in |
| Comment by Githook User [ 20/Jul/18 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: (cherry picked from commit 6b0147211e26239fb15e06fa5555bd3f701d8669) |
| Comment by Githook User [ 20/Jul/18 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: (cherry picked from commit 472d4ecaf989b239e324ef12b39357802d96f607) |
| Comment by Githook User [ 20/Jul/18 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: (cherry picked from commit 461184c1467fb6c130638b27bf1d71962c7e830b) |
| Comment by Githook User [ 20/Jul/18 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: (cherry picked from commit 6b0147211e26239fb15e06fa5555bd3f701d8669) |
| Comment by Githook User [ 20/Jul/18 ] |
|
Author: {'username': 'benety', 'name': 'Benety Goh', 'email': 'benety@mongodb.com'}Message: |
| Comment by Githook User [ 19/Jul/18 ] |
|
Author: {'username': 'benety', 'name': 'Benety Goh', 'email': 'benety@mongodb.com'}Message: |
| Comment by Githook User [ 19/Jul/18 ] |
|
Author: {'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}Message: |
| Comment by Alexander Gorrod [ 18/May/18 ] |
|
bruce.lucas Do you have a workload we can use to reproduce this issue? Or failing that could you attach diagnostic data from a scenario where the symptom happened? |
| Comment by Gregory McKeon (Inactive) [ 15/May/18 ] |
|
Sending this to storage, since they're more familiar with the oldest timestamp semantics on 3.6. We're happy to assist if there's repl work here. |