[SERVER-30883] Fast-path caching of oldest oplog entry Created: 30/Aug/17 Updated: 30/Oct/23 Resolved: 12/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, WiredTiger |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | Eric Milkie |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Execution Team 2020-01-13, Execution Team 2020-01-27, Execution Team 2020-02-10, Execution Team 2020-02-24 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
When the serverStatus command is invoked, its oplog section collects the most recent applied optime and retrieves the first entry from the oplog collection. Because the oldest op is less likely to be present in the WT cache, this may require us to read from disk, and possibly to wait for space during periods of high cache pressure. Given the frequency with which serverStatus is called for FTDC collection and by the Monitoring Agent, we should consider implementing a separate caching mechanism and fast-path this query to avoid I/O and WT cache contention. |
| Comments |
| Comment by Githook User [ 12/Feb/20 ] |
|
Author: {'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}Message: This reverts commit b81a373933e8481fa40f4b6fc692e537df2e307b. |
| Comment by Githook User [ 09/Jan/20 ] |
|
Author: {'name': 'Eric Milkie', 'email': 'milkie@mongodb.com', 'username': 'milkie'}Message: Revert " This reverts commit ece14c8410785b6d1f37a221307b1a0f1ca4e82d. |
| Comment by Githook User [ 08/Jan/20 ] |
|
Author: {'name': 'Eric Milkie', 'email': 'milkie@mongodb.com', 'username': 'milkie'}Message: |