-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.4.4
-
Component/s: WiredTiger
-
None
-
Environment:Single-socket physical machine
XFS on a SATA SSD
Ubuntu 14.04 x64, 4.4 (HWE) kernel
MongoDB 3.4.4
-
Fully Compatible
-
ALL
Dropping collection that is "active" (I'm guessing that used means not checkpointed), possibly if it's concurrent with an active checkpoint, leads to a visible slowdown (queries that took tens of milliseconds start taking hundreds an thousands of milliseconds) and bumps up the checkpoint time. We were hit by this since we upgraded to 3.4, and while the upgrade to 3.4.4 (WT-3207) helped with "inactive" collections (we create/drop collections that are grouped per-day), but dropping "active" collections still leads to latency spikes, and since the system is sized to latency N, when latency becomes 100*N it just can't cope with the load.
The worst part of it that entire database instance is affected, not just the collection or database in question.
SERVER-22199 + WT-2333 and WT-2334 seem to be related.
Attaching the subject log. The WT checkpoint time which is 3.5 sec average for an hour before/after the event spiked to 25 sec (we've seen 45 sec checkpoints in previous days).
- duplicates
-
SERVER-27347 Only close idle cached cursors on the WiredTiger ident that is busy
- Closed