-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[Enhancement] limit tablet write request size #50302
[Enhancement] limit tablet write request size #50302
Conversation
Signed-off-by: silverbullet233 <[email protected]>
Signed-off-by: silverbullet233 <[email protected]>
Signed-off-by: silverbullet233 <[email protected]>
9862259
to
5717597
Compare
Signed-off-by: silverbullet233 <[email protected]>
auto req = _rpc_request.mutable_requests(0); | ||
for (size_t i = 0; i < filter_size; ++i) { | ||
req->add_tablet_ids(tablet_ids[filtered_indexes[from + i]]); | ||
} | ||
} | ||
|
||
if (_cur_chunk->num_rows() < _runtime_state->chunk_size()) { | ||
if (_cur_chunk->num_rows() < _runtime_state->chunk_size() && | ||
_cur_chunk_mem_usage < config::max_tablet_write_chunk_bytes) { |
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.
_cur_chunk->num_rows() <= 0 || (_cur_chunk->num_rows() < _runtime_state->chunk_size() && _cur_chunk_mem_usage < config::max_tablet_write_chunk_bytes) maybe better
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.
clone_empty_with_slot maybe reserve some memory, there maybe no one row in chunk, but memory exceed the limit.
Signed-off-by: silverbullet233 <[email protected]>
097add0
to
580fa07
Compare
Signed-off-by: silverbullet233 <[email protected]>
a53729f
// NOTE: If there are a large number of columns when loading, | ||
// a too small max_tablet_write_chunk_bytes may cause more frequent RPCs, which may affect performance. | ||
// In this case, we can try to increase the value to avoid the problem. | ||
CONF_mInt64(max_tablet_write_chunk_bytes, "536870912"); |
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.
Why not keep the same size of protobuf limit?
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.
Why not keep the same size of protobuf limit?
Because this is not a hard limit, the chunk may exceed it. If it is set to 2GB, serialization will still fail once it exceeds the limit. 512MB is large enough for most scenarios.
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[BE Incremental Coverage Report]❌ fail : 0 / 24 (00.00%) file detail
|
@Mergifyio backport branch-3.3 |
@Mergifyio backport branch-3.2 |
✅ Backports have been created
|
✅ Backports have been created
|
Signed-off-by: silverbullet233 <[email protected]> (cherry picked from commit ce25287)
Signed-off-by: silverbullet233 <[email protected]> (cherry picked from commit ce25287)
Co-authored-by: eyes_on_me <[email protected]>
Co-authored-by: eyes_on_me <[email protected]>
Can we backport it to 3.2? |
Signed-off-by: silverbullet233 <[email protected]> Signed-off-by: zhiminr.ren <[email protected]>
Why I'm doing:
When there are large chunks during the load process, the following error may be returned due to exceeding the size limit of protobuf.
NodeChannel currently only aggregates batches based on the function of the chunk, but does not take into account the size of the chunk.
What I'm doing:
In this PR, I have added chunk mem usage check to avoid generating large pb requests for load tasks
Fixes #issue
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: