-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
In some workloads the bottleneck for creating a checkpoint can be in reconciliation and compression. Since the amount of time a checkpoint takes after it enters the write-leaves phase can affect application thread latencies, it would be nice if the CPU overhead could be shared.
Perhaps if there are multiple eviction threads configured, we could create a queue of pages that need to be written when first starting the checkpoint. That queue is consumed by checkpoint/eviction threads (possibly application threads, if they would otherwise have been helping with eviction?).
Then the CPU overhead of a checkpoint could be spread across multiple CPUs.
This is wild speculation, I haven't through through the complexities of implementing such a scheme.
- is related to
-
SERVER-16736 support more than 1 checkpoint thread for WiredTiger
- Closed