Skip to content
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

Request for a stricter limit on worst-case space-amplification #9561

Open
mdcallag opened this issue Feb 14, 2022 · 0 comments
Open

Request for a stricter limit on worst-case space-amplification #9561

mdcallag opened this issue Feb 14, 2022 · 0 comments

Comments

@mdcallag
Copy link
Contributor

This is a feature request.

Expected behavior

With respect to worst-case space-amplification:

Actual behavior

Full details were provided to the team (sorry, bad OSS behavior) and I used 2 workloads with db_bench

  • in-memory - use fillseq to load 40M KV pairs, run readwhilewriting for 30 minutes, then run overwrite with no writer rate limit for 1 hour
  • IO-bound - same as in-memory, except fillseq loads 800M KV pairs

Then I compared the size at the end of readrandom vs the max size of database directory during overwrite and I will list the ratio of max / initial size here for the in-memory workload.

  • 2.0 for leveled
  • 5.6 for universal
  • 3.5 for blob with a naive config
  • 23.2 for blob with a better config. This is too large and I need to revisit the problem to try and explain it.

The max/initial size ratio for the IO-bound workload using buffered IO and then O_DIRECT

  • 1.2 and 1.4 for leveled
  • 3.8 and failed for universal - by failed I mean the overwrite test failed when the 3T database directory became full. At that point the space-amp was ~6X
  • 1.4 and 1.3 for blob with the naive config
  • 1.7 and 1.7 for blob with the better config
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants