hotpxl opened a new issue, #2601: URL: https://github.com/apache/kvrocks/issues/2601
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/kvrocks/issues) and found no similar issues. ### Version 6b23c5ac2cf17558d167a3305c8f10ecb944637f ### Minimal reproduce step Default configuration but with `stats_dump_period_sec` set (so you can see compaction stats) , `redis-cli set a b`, `redis-cli compact`. ### What did you expect to see? Because of how `level_compaction_dynamic_level_bytes` works, there should be only 1 compaction to L6 (the default bottom-most layer) ### What did you see instead? 1 compaction on each layer and 2 compactions to L6 ### Anything Else? I instrumented rocksdb code and this is because `rocksdb::CompactRangeOptions.change_level` is not compatible with `level_compaction_dynamic_level_bytes`. When `level_compaction_dynamic_level_bytes` is set, `set a b` and `compact` will not compact to L1, it'll jump directly to the last layer (L6). And when `change_level` is set, it then moves this SST file from L6 back to L1. Now when another periodic compaction comes along, it tries to move this file from L1->L2, L2->L3, ... This is why every layer has 1 compaction and the last layer has 2 compactions. If you run a manual compaction at this time, since `change_level` is set, it'll move the SST file to L1 again, resulting in the same churn happening. Obviously this is quite efficiently since these 2 options are trying to undo each other's work.. ### Are you willing to submit a PR? - [ ] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
