[SERVER-22224] $near query uses unbounded memory Created: 19/Jan/16 Updated: 13/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | 3.0.8, 3.2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | RF, WTmem, WTplaybook, query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Sprint: | Query 15 (06/03/16), QE 2022-10-17, QE 2022-10-31, QE 2022-11-14, QE 2022-11-28, QE 2022-12-12, QE 2022-12-26, QE 2023-01-09 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
With following index:
and 10M of the following documents:
run following query, which finds 0 documents:
Result as follows:
|
| Comments |
| Comment by Kyle Suarez [ 26/Sep/22 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Sending this back to the Query Execution triage queue for re-discussion, and to come up with a SWAG estimate on how much work this would be to implement (in the classic engine). After adding the estimate, we can pass this to the Product team for re-prioritization. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by He Lei [ 24/Apr/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
3.7.5 affected. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by shawn [ 11/Jan/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
is 3.6 affected also? | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 03/Jun/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
max.hirschhorn, that stack corresponds to memory allocated by WT for the cache, whereas the memory issue in this case will be outside the cache. If you aren't seeing anything signifcant besides that stack, then I suspect that sample was taken after the query finished running, when the excess memory would have already been freed and all that was left was the WT cache. It can be useful to see a timeseries of call trees, and that can be done using the experimental built-in heap profiler. Running the repro workload above and then visualizing with the timeseries tool:
An alternative view is provided by the calltree tool from the timeseries of call stacks collected by the heap profiler. This view makes it easier to read the stack traces, although it doesn't put it in context with the rest of the metrics like the timeseries tool does. The same two stacks are seen at 1 and 2.
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Max Hirschhorn [ 02/Jun/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Just to give an update on this ticket. Per a suggestion from kamran.khan, I used malloc_history to see the memory allocation of the server when executing the $near query.
I would have expected WorkingSetMember::makeObjOwnedIfNeeded() to appear in the above stack trace intead of WorkingSetCommon::fetch() and the memory allocations from WiredTiger if it were the case that making copies of documents we aren't going to return was causing this issue. Instead, looking that the explain output of the $near query, we can see that the filter {"$not": {"s": {"$eq": 0}}} on the root FETCH stage and that the bounds for the "s" field are [MinKey, MaxKey]. This means that we will scan the entire index subject to the geo bounds, fetch all of the documents, and then return none of them (in the case of the highly selective filter {"$not": {"s": {"$eq": 0}}}). The next step should be to determine why we aren't unionizing the index bounds with the complement of the index bounds for the predicate {"s": {"$eq": 0}}, i.e. [[MinKey, 0), (0, MaxKey]] | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 19/Jan/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, also affects 3.0.8. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 19/Jan/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Is 3.0 affected? |