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

Improve Download Memory Usage #61

Merged
merged 15 commits into from
Oct 8, 2024
Merged

Improve Download Memory Usage #61

merged 15 commits into from
Oct 8, 2024

Conversation

waahm7
Copy link
Contributor

@waahm7 waahm7 commented Oct 4, 2024

Description of changes:
Tokio.spawn doesn't respect the spawn order, which can result in us downloading the first num_concurrency parts in random order. For a workload of 5GB * 100 files, this can lead to very high memory usage, as seen in the diagram below. This PR refactors the exact part to be determined only once the task has been scheduled.

Uploads can also have a similar issue where we read too many parts into memory. To fix that, we will need to refactor our scheduler to be smarter so that we only read the part when we have the permit. (Created: #60)

memory_usage_comparison

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@waahm7 waahm7 requested a review from a team as a code owner October 4, 2024 22:17
Copy link
Contributor

@aajtodd aajtodd left a comment

Choose a reason for hiding this comment

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

What's this do to throughput for download? In particular the warmup/first few runs?

@@ -129,18 +129,30 @@ fn handle_discovery_chunk(

/// Download operation specific state
#[derive(Debug)]
pub(crate) struct DownloadState {}
pub(crate) struct DownloadState {
current_seq: u64,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you not get away with an atomic here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, updated to AtomicU64.

if let Some(stream) = initial_chunk {
let seq = handle.ctx.next_seq();
Copy link
Contributor

Choose a reason for hiding this comment

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

start_seq and seq aren't connected anywhere here, should probably set start_seq to seq instead of hard coded to 1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, we would have to set start_seq = seq+1. I have added a current_seq() function which will return 0 or 1 depending upon we called next_seq or not.

@waahm7
Copy link
Contributor Author

waahm7 commented Oct 7, 2024

What's this do to throughput for download? In particular the warmup/first few runs?

It didn’t help much since we were only doing 125 out of 3840 parts out of order.

@waahm7 waahm7 merged commit 3dd20c8 into main Oct 8, 2024
12 of 13 checks passed
@waahm7 waahm7 deleted the waqar/download-perf branch October 8, 2024 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants