-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
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.
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, |
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.
Can you not get away with an atomic here?
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, updated to AtomicU64.
if let Some(stream) = initial_chunk { | ||
let seq = handle.ctx.next_seq(); |
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.
start_seq
and seq
aren't connected anywhere here, should probably set start_seq
to seq
instead of hard coded to 1
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, 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.
It didn’t help much since we were only doing 125 out of 3840 parts out of order. |
Description of changes:
Tokio.spawn
doesn't respect the spawn order, which can result in us downloading the firstnum_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)
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.