-
Type: Bug
-
Resolution: Done
-
Priority: Critical - P2
-
Affects Version/s: 3.0.1
-
Component/s: WiredTiger
-
Fully Compatible
ISSUE SUMMARY
Because of an interaction between the process for dropping and creating collections with the WiredTiger storage engine, the process of dropping a collection and freeing resources used by that collection can block creating new collections.
USER IMPACT
Workloads that involve large volumes of collection drop operations may experience performance degredation.
WORKAROUNDS
None.
AFFECTED VERSIONS
3.0.0, 3.0.1, 3.0.2
FIX VERSION
The fix is included in the 3.0.3 production release.
Original description
Dropping a collection can take a long time under WiredTiger because can require freeing a large number of allocated buffers. See SERVER-17907 for information on reproducing.
While this is occuring creating a new collection may be blocked for a substantial time. The create was accomplished in this test by inserting a record into a non-existent collection, so the stack traces below show the createCollection happening within insertOne. It is blocked in two different places:
- From A to B it's blocked waiting for the db lock. This occurs synchronously with the drop command itself, which is busy freeing buffers.
- From B to C it's blocked waiting to update the metadata table. This occurs while synchronously with dropAllQueued (not shown in the screenshot below), which is also busy freeing buffers.
Total timeline below is about 3.5 minutes, so total time blocked is about 2 minutes.
- is related to
-
SERVER-17907 B-tree eviction blocks access to collection for extended period under WiredTiger
- Closed