[SERVER-14525] Perf regression in 2.6.2 caused by not caching plans that tie during plan ranking Created: 10/Jul/14 Updated: 25/Jun/15 Resolved: 14/Apr/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Alvin Richards (Inactive) | Assignee: | David Storch |
| Resolution: | Duplicate | Votes: | 12 |
| Labels: | 28qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
For scenarios in which plans repeatedly tie, Original DescriptionProblem:
Bad Githash: 213700b3af4d53ce7e808dce2c638d98fc4f91db
|
| Comments |
| Comment by David Storch [ 14/Apr/15 ] | |||||||||||||||||||||||||||
|
Apologies for the delay in our response. I believe your understanding of the issue is correct. Please let me know if you have any further questions. Best, | |||||||||||||||||||||||||||
| Comment by David Storch [ 14/Apr/15 ] | |||||||||||||||||||||||||||
|
As of 81a1f70b87b3f3754 (see | |||||||||||||||||||||||||||
| Comment by Steve Ranck [ 19/Mar/15 ] | |||||||||||||||||||||||||||
|
I'd like to confirm that I understand this issue correctly. We make extensive use of indexes in the form of:
According to this issue, is it correct that the following query will never cache a plan given the indexes above?
| |||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 17/Oct/14 ] | |||||||||||||||||||||||||||
|
flavio@alicubi.net can you share how you are testing and measuring the impact? Do you have a synthetically generated test you can just attach to the ticket or are you using a copy of your actual data/operations to measure load? Also, what metrics are you collecting in the tests - can you post what exact numbers are like? | |||||||||||||||||||||||||||
| Comment by flavio alberti [ 17/Oct/14 ] | |||||||||||||||||||||||||||
|
I retested in mongodb 2.6.5, but | |||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 19/Sep/14 ] | |||||||||||||||||||||||||||
|
Fixing because (a) plans should not tie as often (b) cost of re-racing will be lower. alvin can you retest this on 2.6.5 candidate when that fix goes in there? | |||||||||||||||||||||||||||
| Comment by flavio alberti [ 13/Sep/14 ] | |||||||||||||||||||||||||||
|
I hope this regression can be fixed asap in 2.6, otherwise we can not upgrade our cluster in production. We can not apply any workaround (hint operator at the end of the queries) whiteout changing a lot code and queries. | |||||||||||||||||||||||||||
| Comment by rgpublic [ 12/Aug/14 ] | |||||||||||||||||||||||||||
|
(Is this the same as Perhaps you might want to reconsider the importance of this. As you are probably well aware of there have been numerous similar problems introduced with the new query optimizer supporting index intersection. From a mere user POV it is currently a rather huge regression to the 2.4.x versions IMHO. We need to skip using the 2.6.x versions altogether due to all these problems and hope the dust settles with the 2.8.x series. As soon as we try to update the whole database grinds to a halt because many queries run way longer than under 2.4.x. The main problem here is the fact that it's a regression. We have an existing code-base that works great and fast under 2.4.x. We want to update to make use of the new features in 2.6.x. We can't until all queries run at least in similar time as before. MongoDB's great feature to support ad-hoc queries means that we have spread lots of different queries all over our code base and it's just not practical to look for queries that worked great before and add hints everywhere just to explain MongoDB that it should use an a_b-index if we're querying on, well, a and b. Just my $0,02. Appreciate your hard work. | |||||||||||||||||||||||||||
| Comment by Alvin Richards (Inactive) [ 10/Jul/14 ] | |||||||||||||||||||||||||||
|
Query plans look the same on 2.6.1 and 2.6.3
|