New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write-amp increased for fillseq with universal compaction #10082
Comments
In current implementation, if universal compaction needs to schedule a compaction for L0->L0, we couldn't do trivial move. The basic idea for universal compaction is that each L0 file is treated as a sorted run, and one major goal of the algorithm is to limit total number of sorted runs. If we don't do trivial moves, it won't happen. I think one work-around, which is actually the recommended configuration practice, is to use num_levels at least a few larger than level0_file_num_compaction_trigger. I saw you are using |
Thanks. I will repeat the benchmarks. |
I updated https://github.com/facebook/rocksdb/wiki/Universal-Compaction for trivial move condition. |
I will update tools/benchmark.sh to use num_levels=40 Repeated tests with num_levels = 8, 20 and 40. Summary for cached workload:
Summary for IO-bound workload:
For cached by RocksDB workload:
For IO-bound workload
|
Summary: See facebook#10082 for more details. Trivial move isn't done for universal when compaction is from L0 into L0. So a too small value for num_levels with db_bench means there will be fewer trivial moves with universal and that means that write-amp will increase. Test Plan: run it Reviewers: Subscribers: Tasks: Tags:
Summary: See #10082 for more details. Trivial move isn't done for universal when compaction is from L0 into L0. So a too small value for num_levels with db_bench means there will be fewer trivial moves with universal and that means that write-amp will increase. Pull Request resolved: #10158 Test Plan: run it Reviewed By: siying Differential Revision: D37122519 Pulled By: mdcallag fbshipit-source-id: 1cb39049676f68a6cc3ea8d105a9965f89d4d09e
This occurs after 4.1 but in or before 5.1.4.
Notice in the compaction IO stats below that with v4.1 there is data in L0 and L7. While with v5.1.4 there is data in L0, L2, L3, L4, L5, L6. For v5.1.4 only trivial move is used for L2 through L6. But with v5.1.4 the amount of compaction within L0 is larger -- see the Write(GB) column in the compaction IO stats.
I don't know whether the issue is from the extra compaction in L0 or from the extra trivial moves from the additional levels. Also see issues 10075 and 9423.
Perf for 4.1
Perf for 5.1.4
Compaction IO stats at test end for 4.1
Compaction IO stats at test end for 5.1.4
Command lines for 4.1 and 5.1.4
The text was updated successfully, but these errors were encountered: