[SERVER-54004] Improve oplog truncation thread's log level 0 logging Created: 25/Jan/21 Updated: 29/Oct/23 Resolved: 05/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Bynn Lee |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, newgrad | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Execution Team 2021-02-08 | ||||
| Participants: | |||||
| Linked BF Score: | 123 | ||||
| Description |
|
The log message that always show up for oplog truncation, which can indicate when oplog truncation is taking a long time (high resource consumption, perhaps), with log-level 1 is: "WiredTiger record store oplog truncation finished in: <elapsedMillis>ms" A more informative message for debugging, which communicates an oplog size guess, might be the log-level 1 prior message: "Finished truncating the oplog, it now contains approximately <sizeInfo_numRecords_load> records totaling to <sizeInfo_dataSize_load> bytes" Or, better yet, we could combine them into one message at log-level 0. |
| Comments |
| Comment by Githook User [ 05/Feb/21 ] |
|
Author: {'name': 'Bynn Lee', 'email': 'bynn.lee@mongodb.com', 'username': 'bynn'}Message: |