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

Limit size of blocks to X bytes on compaction. #3068

Closed
bwplotka opened this issue Aug 25, 2020 · 18 comments
Closed

Limit size of blocks to X bytes on compaction. #3068

bwplotka opened this issue Aug 25, 2020 · 18 comments

Comments

@bwplotka
Copy link
Member

This is to ensure the scalability of the compactor.

Tricky part: How to shard block, what label to put, or maybe vertical compaction?

@bwplotka
Copy link
Member Author

bwplotka commented Oct 30, 2020

On it now, proposal to be created.

bwplotka added a commit that referenced this issue Nov 2, 2020
…k size).

Related to #1424 and #3068

Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
@stale
Copy link

stale bot commented Dec 29, 2020

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Dec 29, 2020
@bwplotka
Copy link
Member Author

Still in progres. Vertical block sharding has to be designed and implemented.

@bwplotka
Copy link
Member Author

bwplotka commented Feb 1, 2021

Proposal is half done: #3390

The plan is to team up with LFX mentee for knowledge sharing 🤗

@someshkoli
Copy link
Contributor

someshkoli commented Feb 3, 2021

Hey @bwplotka, I'd like to pick this up again and work on it.

Proposal is half done: #3390

From what I understand, we need to shard the block after certain size continuously so that it won't hit the size limit (64gb as for now). Also how are we planning to shard these blocks, I remember planning of breaking blocks into half of the compacted size until its below the threshold value, Any pointers on that ?

@bwplotka
Copy link
Member Author

bwplotka commented Mar 29, 2021

cc @Biswajitghosh98 🤗

@stale
Copy link

stale bot commented Jun 6, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Jun 6, 2021
@onprem onprem removed the stale label Jun 11, 2021
@stale
Copy link

stale bot commented Aug 10, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Aug 10, 2021
@GiedriusS GiedriusS removed the stale label Aug 11, 2021
@stale
Copy link

stale bot commented Oct 11, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Oct 11, 2021
@stale
Copy link

stale bot commented Oct 30, 2021

Closing for now as promised, let us know if you need this to be reopened! 🤗

@oronsh
Copy link
Contributor

oronsh commented Dec 14, 2021

How about a new flag to set max time range to apply compaction on? So if for example the compactor detects metadata with now - max_time > max_compaction_timerange exclude the block.
This will probably help reducing size so one could possibly set the compactor to compact only 4 hours old blocks max for example.

@stale stale bot removed the stale label Dec 14, 2021
@stale
Copy link

stale bot commented Mar 2, 2022

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Mar 2, 2022
@alvinlin123
Copy link

Where is the proposal for this feature?

@stale stale bot removed the stale label Apr 16, 2022
@bwplotka
Copy link
Member Author

bwplotka commented Jun 23, 2022

Here: #4191

@bwplotka
Copy link
Member Author

Update: Currently compactor will not create bigger blocks than with the index configured with compact.block-max-index-size (hidden flag). Thus this issue can be closed.

I will add another one with more dynamic solution that actually can split blocks vertically.

@bwplotka
Copy link
Member Author

Created for tracking #5437

@yeya24
Copy link
Contributor

yeya24 commented Jun 24, 2022

This feature is mainly about limiting block index size? Chunk sizes are not included

@BouchaaraAdil
Copy link
Contributor

BouchaaraAdil commented Sep 16, 2024

@bwplotka how can we control Block sizes?
weh have blocks that are over 100GB

Start Time: June 12, 2024 1:00 AM
End Time: June 18, 2024 1:00 AM
Duration: 6 days
Series: 56716960
Samples: 52166082084
Chunks: 462569560
----------------
Total size: 109.90 GiB
Chunks: 98.72 GiB (89.82%)
Index: 11.18 GiB (10.18%)
Daily: 18.32 GiB / day
----------------
Resolution: 0
Level: 4
Source: compactor

we see this error in these cases:

 | ts=2024-09-14T17:29:55.251619424Z caller=compact.go:546 level=error msg="retriable error" err="first pass of 

downsampling failed: 2 errors: downsampling to 5 min: download block 01J5WJ3G8FZ4CXAHWPVDYG4YB6: get file 

01J5WJ3G8FZ4CXAHWPVDYG4YB6/chunks/000020: The difference between the request time and the current time is 

too large.; downsampling to 5 min: download block 01J3DQ5Q98458FHBA84XG996GAA6: get file 

01J3DQ5Q16A00BA8484HVH46/chunks/000116: The difference between the request time and the current time is too large." |  

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.

8 participants