[SERVER-34998] Ignore oplog timeout in serverStatus opLatencies Created: 15/May/18 Updated: 13/Jun/18 Resolved: 05/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Querying |
| Affects Version/s: | 3.4.15 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Kevin Arhelger | Assignee: | David Storch |
| Resolution: | Duplicate | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Query 2018-06-18 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
The opLatencies section of serverStatus was added in MongoDB 3.4. These metrics are collected by FTDC, Ops Manager/Cloud Manager monitoring, and third party tools. On an idle replica set, read latencies can be observed in the 5000ms range due to replication timeout. This is confusing for anyone observing these metrics and they may believe there is a performance problem, solely based on these artifacts. When a steady write load is applied, these metrics even out. Splitting oplog latencies out from this metric would prevent this confusion, but still allow diagnosis of replication issues. |
| Comments |
| Comment by David Storch [ 05/Jun/18 ] |
|
kevin.arhelger, excluding time spent blocking for awaitData from various debug output, including db.serverStatus().opLatencies was implemented in I'm closing this ticket as a duplicate of |
| Comment by Bruce Lucas (Inactive) [ 15/May/18 ] |
|
I don't recall seeing these logged as slow operations in mongod log. I wonder why they show up in opLatencies and not the log? In any case agreed these aren't really op latencies. |