[SERVER-60374] Unique index performance degradation after upgrading from 4.4.3 to 5.0.3 Created: 01/Oct/21  Updated: 11/Jul/22  Resolved: 11/Jul/22

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

Type: Bug Priority: Major - P3
Reporter: Gábor Mező Assignee: Eric Sedor
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:
  1. create a collection with a unique index
  2. save few hundred documents
  3. deleteMany({})
  4. GOTO 2

The required time between 2-4 slowly increases with 5.0.3, but stay the same with 4.4.3.

Participants:

 Description   

The issue is the following:

I have a testing environment with bunch of integration tests running one after the other. They are using MongoDB, and using the same database and collections.

I only have some unique indices there and there, there are no regular indices.

Between fixtures I reset the database just by calling collection.deleteMany({}) in each collection.

In 4.4.3 it was fine, but after 5.0.3 upgrade I noticed a serious performance degradation. After some investigation, I found that every test case took a slightly more time to run than the previous one, and it slowly added up, and to the end I can see test cases took 2x more time to finish than did with 4.4.3.

What I ended up with, when I drop and recreate indices between fixtures, I get the same performance as it was with 4.4.3.

So I suspect that somehow unique indices of deleted entries are not getting deleted automatically causing performance degradation for live data.



 Comments   
Comment by Eric Sedor [ 11/Jul/22 ]

We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Thank you!

Comment by Brooke Miller [ 12/May/22 ]

Hi gabor42mezo@gmail.com,

We still need additional information to diagnose the problem. If this is still an issue for you, would you please provide the information Eric requested above?

Regards,

Brooke

Comment by Eric Sedor [ 04/Mar/22 ]

Thanks gabor42mezo@gmail.com; Since I've been unable to reproduce this, would you be able archive (tar or zip) the $dbpath/diagnostic.data directory (the contents are described here) for this test on both 4.4.11 and 5.0.6, and attach them to this ticket?

Comment by Gábor Mező [ 04/Mar/22 ]
  1. Confirmed, all settings are the same.
  2. Don't know exactly, but approx. over hundreds.
  3. I don't know where this came from. Overall test running performance is way much worse. I can make it much better when I delete all indices before calling deleteMany and recreate them afterwards when the database gets empty.
  4. Various documents, 20 on fields average. They can be quite large because of internal arrays.
  5. I'm only using unique indices during testing, because added functionality of indices is to prevent duplicates arise.
Comment by Gábor Mező [ 12/Feb/22 ]

Hey, sorry, the notification got landed in my spam folder. I'm gonna get back to you on Monday.

Comment by Eric Sedor [ 31/Jan/22 ]

Hi gabor42mezo@gmail.com, can I follow up with you on my questions above?

Comment by Eric Sedor [ 20/Oct/21 ]

Hi gabor42mezo@gmail.com, and thank you so far. I've been investigating the possible relationship to SERVER-57221, WT-7653, and WT-7912 but can't conclusively link your report to these so far.

I've also attempted an initial reproduction without much success. Can you please provide some additional information about your proposed reproduction:

  1. Can you confirm the writeConcern you are using for your reproduction, and confirm that it is the same for 4.4.3 and 5.0.3?
  2. Over how many iterations do you see what kind of magnitude of increase in time?
  3. Can you clarify if the timing you describe includes both the insert and delete steps? Have you confirmed the time increase is on deleteMany only?
  4. Can you describe the documents you are inserting in terms of size/field count?
  5. Are there other indexes on the collection, and if so how many and of what field counts?
Generated at Thu Feb 08 05:49:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.