-
Type: Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
-
None
I'm seeing two things when I try to run medium-lsm-compact.wtperf (after WT-1053):
1. There is an active chunk in the tree when compact starts. We don't do anything to force it to disk until the connection is closed after the compact. Then when we reopen in read-only mode, we get aggressive and merge all over again, just to get this one small chunk merged into the tree.
2. Compact sometimes gives up early. I think what happens is that the merging thread gets stuck somewhere outside the main loop (like closing the bulk cursor and writing all the internal nodes for a merged chunk). That doesn't increment the merge activity counter, so compact thinks that merges are done.
I don't like my solution for 1 – wtperf can force this chunk to disk by closing and reopening the connection before the compact. A better solution would be for LSM compact to force all chunks to be on disk before kicking off the compaction.
- related to
-
WT-1053 compact on 2b items takes 100+x longer
- Closed