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

quantification of compaction algorithms #7770

Closed
1 of 2 tasks
Tracked by #8001
problame opened this issue May 15, 2024 · 3 comments
Closed
1 of 2 tasks
Tracked by #8001

quantification of compaction algorithms #7770

problame opened this issue May 15, 2024 · 3 comments
Assignees
Labels
a/test Area: related to testing c/storage/pageserver Component: storage: pageserver

Comments

@problame
Copy link
Contributor

problame commented May 15, 2024

Child of 2024Q2 compaction work: #8001

This epic tracks the efforts to quantify any compaction algorithm's outcomes.

We had a brainstorming session some time back to come up with an (incomplete) set of potentially useful metrics: https://www.notion.so/neondatabase/Productionize-Tiered-Compaction-eca9b06aa1ae4c62bdf6cf40ab002eb6?pvs=4

Meeting notes / ideas:

  • point-in-time efficiency: Use layer map dump / keyspace dump (not actually measure it by access)
  • total space efficiency:
    • (logical size + wal in PITR window) = synthetic size, can just use that
    • sum(all layer files in index_part.json) => just that

Demo test case to adapt / apply the Python helpers to:

  • test_gc_feedback

Refs

  1. run-benchmarks
@problame problame changed the title test_gc_feedback: duplicate & adapt to measure / regress-test point-in-time space efficiency python infra to measure total-space-efficiency & point-in-time space efficiency May 15, 2024
@jcsp jcsp added c/storage/pageserver Component: storage: pageserver a/test Area: related to testing labels May 20, 2024
@problame
Copy link
Contributor Author

This week:

problame pushed a commit that referenced this issue Jun 10, 2024
A simple API to collect some statistics after compaction to easily
understand the result.

The tool reads the layer map, and analyze range by range instead of
doing single-key operations, which is more efficient than doing a
benchmark to collect the result. It currently computes two key metrics:

* Latest data access efficiency, which finds how many delta layers /
image layers the system needs to iterate before returning any key in a
key range.
* (Approximate) PiTR efficiency, as in
#7770, which is simply the
number of delta files in the range. The reason behind that is, assume no
image layer is created, PiTR efficiency is simply the cost of collect
records from the delta layers, and the replay time. Number of delta
files (or in the future, estimated size of reads) is a simple yet
efficient way of estimating how much effort the page server needs to
reconstruct a page.

Signed-off-by: Alex Chi Z <chi@neon.tech>
@problame problame changed the title python infra to measure total-space-efficiency & point-in-time space efficiency quantification of compaction algorithms Jun 10, 2024
@problame
Copy link
Contributor Author

This week, @problame to address his follow-up requests from #7867 (review)

@problame
Copy link
Contributor Author

This issue was part of

In the end, that work expanded into Q3 and we focussed solely on bottommost compaction.

Bottommost compaction is very deterministic and hence, the existing quantification work in test_gc_feedback (#7867) is sufficient to qualify & quantify it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a/test Area: related to testing c/storage/pageserver Component: storage: pageserver
Projects
None yet
Development

No branches or pull requests

3 participants