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

Aggregate memory_units_t in fetch to reduce cross-shard calls #12092

Merged
merged 1 commit into from
Jul 14, 2023

Conversation

ballard26
Copy link
Contributor

By aggregating memory_units_t from the same shard together we reduce cross shard function calls from linear to the number of fetched partitions to 1.

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v23.1.x
  • v22.3.x
  • v22.2.x

Release Notes

  • none

@StephanDollberg
Copy link
Member

image

@github-actions github-actions bot removed the area/k8s label Jul 14, 2023
@ballard26 ballard26 changed the title Draft: aggregate memory_units_t to reduce cross-shard calls Aggregate memory_units_t in fetch to reduce cross-shard calls Jul 14, 2023
@ballard26 ballard26 marked this pull request as ready for review July 14, 2023 16:36
@ballard26 ballard26 requested a review from dotnwat July 14, 2023 16:36
By aggregating memory_units_t from the same shard together we reduce
cross shard function calls from linear to the number of fetched
partitions to 1.

From @StephanDollberg
Don't submit empty and check sem counts instead of has_data.

Co-authored-by: Stephan Dollberg <stephan@redpanda.com>
@@ -263,7 +275,7 @@ static ss::future<read_result> do_read_from_ntp(
ssx::semaphore& memory_sem,
ssx::semaphore& memory_fetch_sem) {
// control available memory
read_result::memory_units_t memory_units;
read_result::memory_units_t memory_units(memory_sem, memory_fetch_sem);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was this a latent bug?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, if for some reason read_from_partition reads data even though skip_read is set a seg fault will occur when we try to adjust the semaphore units in memory_units_t. This doesn't happen today, but one never knows what the future holds.

This avoids this potential issue by setting the semaphore units to some reasonable default state.

@travisdowns
Copy link
Member

Looks good to me. If this is still causing a burden after these optimizations, one avenue for investigation would be to see if we are in practice returning a small number of units for each fetch request, say 100s of KBs. In that case, we might reasonably say that each core can hold say 10 MB of free but not returned units from another core, and so buffer/batch the units until that number is hit which might coalesce a lot messages into 1.

@ballard26 ballard26 merged commit 6e50790 into redpanda-data:dev Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants