[SERVER-20327] Query Performance Regression in Mongo-Perf Created: 04/Sep/15  Updated: 05/Feb/16  Resolved: 12/Oct/15

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

Type: Bug Priority: Major - P3
Reporter: David Daly Assignee: James Wahlin
Resolution: Done Votes: 0
Labels: mpreg
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Backwards Compatibility: Major Change
Operating System: ALL
Sprint: CAP 9 (09/18/15)
Participants:
Linked BF Score: 0

 Description   

WT Standalone variant query is failing.

Two tests flagged:

  1. Queries.IntIdFindOne
  2. Queries.IntNonIdFindProjectCovered

Other tests not flagged, but looked regressed from visual inspection

  1. Queries.TwoInts
  2. Queries.Text.FindSingle
  3. Queries.Text.FindThreeWords
  4. Queries.Text.FindPhrase

Those tests are not failing on MMAP, but that looks like it may be due to higher noise margins on the MMAP tests.



 Comments   
Comment by Githook User [ 18/Sep/15 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-20327 Don't copy indexes catalog entry to array before parsing
Branch: master
https://github.com/mongodb/mongo/commit/1aec175308cb91b43efd6bafc145054222db7748

Comment by Githook User [ 11/Sep/15 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-20327 Don't check index catalog when recording usage stats
Branch: master
https://github.com/mongodb/mongo/commit/8b205afd0ae74fd7351bc183e39b8931044f3987

Comment by David Daly [ 09/Sep/15 ]

From off-line discussion with james.wahlin it seems he has a good lead on this now. Moved to SERVER and assigning to James to continue on.

Comment by David Daly [ 08/Sep/15 ]

I can reproduce this on my local linux box now on Queries.IntIdFindOne, but it is fairly sensitive. In order to reproduce it, I had to pin the mongod processes to certain cores, and the mongo-perf to other cores. I also have hyperthreading and frequency scaling off on my linux box to match the evergreen environment.

I also think this is showing up in other mongo-perf test suites, sometimes just above 5% and sometimes just below, causing the tests to change from red to green and back. Other tests include

  • Insert.IntIDUpsert from the insert suite (upsert) (more visible on mmap that WT)
  • Mixed.FindOneUpdateIntId-50-50 for mmap

james.wahlin I'm beginning to things this is real, but not sure how to proceed on it because of the restrictions needed to repro. Are there useful stats I could collect for you on this from serverStatus or something else? Is there a possibility that this would get worse with higher core counts and threading (i.e., more contention on the stats?)

Comment by David Daly [ 04/Sep/15 ]

This is visible in ae9df7fb11. Running one more commit before that, but don't expect the regression to be present there.

Comment by David Daly [ 04/Sep/15 ]

First visible in commit ce660e56d9. There are 5 previous commits that didn't run. Scheduling likely ones.

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