[SERVER-21546] planCacheListQueryShapes should return cursor Created: 19/Nov/15  Updated: 06/Dec/22  Resolved: 18/Jan/18

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

Type: Bug Priority: Major - P3
Reporter: Akira Kurogane Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

In a busy collection the following error was encountered.

mgoll@hostxyz ~ $ mongo mydatabase
MongoDB shell version: 3.0.7
connecting to: mydatabase
big:PRIMARY> db.mycollection.getPlanCache().listQueryShapes()
2015-11-14T07:24:31.438-0800 E QUERY    Error: error: {
	"$err" : "BSONObj size: 66141993 (0x3F13F29) is invalid. Size must be between 0 and 16793600(16MB)",
	"code" : 10334
}
    at Error (<anonymous>)
    at DBQuery.next (src/mongo/shell/query.js:259:15)
    at DBCollection.findOne (src/mongo/shell/collection.js:189:22)
    at DB.runCommand (src/mongo/shell/db.js:58:41)
    at DBCollection._dbCommand (src/mongo/shell/collection.js:105:21)
    at PlanCache._runCommandThrowOnError (src/mongo/shell/collection.js:1716:32)
    at PlanCache.listQueryShapes (src/mongo/shell/collection.js:1727:17)
    at (shell):1:27 at src/mongo/shell/query.js:259

Many of the queries made against this collection have unusually large clauses (over 4kB) so I hypothesize that size multiplied by the default internal query cache size has allowed 16MB to be exceeded.

Maybe a normalized query shape should be saved instead of originals which may have large query args, particularly due to arrays. The normalized form will keep the query shapes small and make it much harder to exceed 16MB.



 Comments   
Comment by Akira Kurogane [ 18/Jan/18 ]

3.0 will reach EOL soon. No occurrences ever noticed since by me either. Closing.

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