[SERVER-4397] Log table scans. Created: 30/Nov/11  Updated: 30/Jan/15  Resolved: 30/Jan/15

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

Type: Improvement Priority: Major - P3
Reporter: Kyle Banker Assignee: David Storch
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-7754 add index/query plan to currentOp and... Closed
Participants:

 Description   

If a query or a command (such as count) is doing a table scan, we should note that in the logs explicitly.

In addition, we should add a table scans counter for both queries and commands to the server status results. That way, we can graphs table scans in MMS. This would help us diagnose these kinds of problems without having to look at the logs.

If it's difficult to determine exactly what qualifies as a table scan, I'd recommend a simple heuristic. For instance, we could log whenever nscanned > 10n and when nscanned > 1000.



 Comments   
Comment by David Storch [ 30/Jan/15 ]

In 2.6 and onwards, the query plan is included in the planSummary field of the query log lines. This work was done under SERVER-7754. A collection scan plan is indicated in these logs with the string "planSummary: COLLSCAN". Consider the following code, which enables logLevel 1 and then runs a collection scan:

db.adminCommand({setParameter: 1, logLevel: 1});
db.coll.insert({_id: 1});
db.coll.find();

A 2.6.7 server generates the following log line:

2015-01-30T16:50:01.242-0500 [conn1] query test.coll planSummary: COLLSCAN ntoreturn:0 ntoskip:0 nscanned:1 nscannedObjects:1 keyUpdates:0 numYields:0 locks(micros) r:181 nreturned:1 reslen:38 0ms

Closing as a duplicate of SERVER-7754.

Generated at Thu Feb 08 03:05:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.