[SERVER-37031] The scanned and returned counts in server status should not include oplog queries Created: 06/Sep/18  Updated: 13/Sep/18  Resolved: 13/Sep/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Alyson Cabral (Inactive) Assignee: Asya Kamsky
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Other MongoDB products use the ratio or returned vs scanned to indicate healthy queries and good indexes. In certain cases, we alert end users if this ratio is too high (over 1000)

However, since oplog queries are included in this global metric, change streams and the triggers built off change streams cause these alerts to happen much more frequently. Additionally, in the case of oplog queries, the ratio does not indicate a bad query and may just indicate a selective change stream. These alerts are not at all actionable in these cases.

The solution is to remove oplog queries from the scanned and returned counts and add a new metric which includes the oplog queries. 



 Comments   
Comment by Asya Kamsky [ 13/Sep/18 ]

> ratio or returned vs scanned

The numbers in db.serverStatus().metrics that I assume you refer to (in queryExecutor for scanned and scannedObjects) are instance-wide and accurately reflect number of documents and index entries examined.

They should not be directly compared to the number in metrics.document.returned as this is a very unreliable "proxy" for healthy queries and good indexes.  For example, any aggregation that returns "count" will return exactly one document but it may look at hundreds or thousands (or millions) of index entries and considerably skew the ratio, even though it's as efficient as it can possibly be.

Oplog queries contribute to the overall load of the cluster so looking at more oplog entries will negatively contribute to the overall load.

 

Generated at Thu Feb 08 04:44:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.