-
Type: Bug
-
Resolution: Duplicate
-
Priority: Blocker - P1
-
None
-
Affects Version/s: 3.0.5
-
Component/s: Storage
-
None
-
ALL
-
Mongo 3 has an O(N^2) perf issue where N is the number of collections in a database. This is a regression from 2.x. For our dataset this causes a ~15 minutes hang, making mongo 3 completely unusable.
The hang can be hit in many ways, including:
1. When calling db.getCollectionNames().
2. When starting mongod.
3. When doing a mongodump.
4. When a secondary mongod server in a replica set transitions to be primary.
The O(N^2) nature can be clearly seen by this chart showing measured time to perform a db.getCollectionNames() for a given number of collections. There's also an attached graph showing a quadratic best fit.
Number Collections (in 1000s) | list collections time (seconds) |
---|---|
1 | 0.164 |
2 | 0.464 |
4 | 1.6 |
8 | 6.1 |
16 | 24 |
32 | 95 |
64 | 439 |
Context:
- We have a multi-tenant system, where each tenant is served by a new collection.
- As a result, we have on the order of 100,000 collections in a database.
- We started upgrading to mongo 3 in our production environment, but ran into this issue (fortunately before we upgraded the primary) and had to do an emergency rollback to 2.6.
- We're now stuck on 2.6 for the moment, but extremely eager to get the benefits of mongo 3 to address pressing issues in production.
Can you please acknowledge this bug and provide an estimate for when it can be fixed and released?
- duplicates
-
SERVER-18624 listCollections command should not be O(n^2) on MMAPv1
- Closed