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

ingester: Produce bigger out-of-order blocks for old data #9911

Closed
codesome opened this issue Nov 15, 2024 · 0 comments · Fixed by #10035
Closed

ingester: Produce bigger out-of-order blocks for old data #9911

codesome opened this issue Nov 15, 2024 · 0 comments · Fixed by #10035

Comments

@codesome
Copy link
Member

Is your feature request related to a problem? Please describe.

When you configure a large out of order window, even a single sample in a 2hr window will lead to a block, which then compactor has to discover, compact, and cleanup. It becomes a problem when there are 1000s of such blocks, making the block cleanup and bucket index update take forever. While there are ways to make the block cleanup and bucket index update faster, why not fix something at the - where we create the blocks.

Describe the solution you'd like

The solution I am proposing is for this part of the code.

Instead of creating blocks of 2h range always for out-of-order data, if the data is for the days before the current day, compact them into 24h blocks, and only compact 2h blocks for the current day.

  • This way, in the best case, there will be 12x reduction in out-of-order blocks if there is large out of order window spanning multiple days and we get unlucky with OOO samples in all of the 2h windows.
  • Even if OOO samples span two 2h windows in the previous days, there will still be 2x reduction in blocks for that range.
  • In the worst case, there is no change, i.e. just 1 block.

Describe alternatives you've considered

Additional context

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant