Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add ability to limit the number of segments killed in kill task #14662
Add ability to limit the number of segments killed in kill task #14662
Changes from 17 commits
142d548
fa48bd0
72e2a8b
4364f63
c71c69f
d9fb724
c90e804
3f7ddc9
be58f1c
3a16585
f08bf89
5509841
b98c30f
e52410a
0347e08
3d33819
ea99715
e15cfce
3cf2bd8
d853a03
2eccb33
66153db
3420936
48b4938
c95f13b
48e6fdc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of dynamic configuration, should we have a dedicated auto-kill config similar to auto-compaction? I think that will ease config management a bit. We can then move all these kill* properties to the dedicated kill config and deprecate the existing dynamic kill config. What do y'all think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered this as well 😆 . I thought since other kill properties are already here at this level to expand and add more. I frankly didnt want to have to deal with the resolution of properties from multiple possible configs, deprecated and new, so decided against it. If you feel strongly let me know. And lets see what others think as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of pruning out the unused segments up here, have we considered pushing down the limit to the metadata query so we ask only what we want? I think that should considerably reduce the load on the metadata store, reduce the lock duration, etc, for unused segments that aren't killed in a run anyway. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it was best to mark all segements in interval specified as unused. Seemed less expensive than actually deleting the segment from deep storage, and other things involved in killing the segment. I did consider this though. But with the limit also applied to marking unused, a user might need multiple requests to mark segments in interval as unused, where as if the limit is only applied to kill, then all segments in interval are marked unused, and if we hit limit on kill, auto kill will clean up eventually, if enabled. Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the comment was referring to something different, about adjusting
RetrieveUnusedSegmentsAction(getDataSource(), getInterval()))
so that it can accept a limit and return a smaller set of unused segmentsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes! sorry, I misunderstood, fixing now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, kill tasks shouldn't mark stuff unused at all. It's best if there is a time delay between markings things unused and permanently deleting them. It's possible for people to make mistakes with what they delete, and we want the mistakes to be undoable for some period of time.
I think the best thing to do in general is actually deprecate the
markUnused
parameter, and focus on workflows that are like:kill
tasks)Btw, an important part of making this work is including a buffer period between when a segment is marked unused, and when autokill would remove it. This was discussed in #12526 although I am not sure what the current status is.
For this patch, IMO the best approach is to have the Coordinator send a list of segments to the
kill
task, rather thaninterval
+maxSegmentsToKill
. This will make it easier to implement the buffer period we need for autokill later— the Coordinator would be in charge of determining which specific segments are killable, and it would need thekill
task to respect that specific list. This also side-steps the issue withmarkAsUnused
, since themaxSegmentsToKill
parameter would no longer exist.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your input @gianm . This makes sense to me. I guess kill tasks will have another config property added, like
segmentIds
, and if that is set, the killTask will ignore the other config properties likeinterval
anddatasource
?I guess one down side of this is that is makes the killTask harder to use by end users, as they now will need to know the ids of segments that they want to kill, if they want to do so manually. But I guess we will have the delete by interval fallback that exists now, if the user still wished to delete segments that way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a new task type to kill unused segments by id.