-
Notifications
You must be signed in to change notification settings - Fork 6k
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
[tune] Release test for durable multifile checkpoints #34860
[tune] Release test for durable multifile checkpoints #34860
Conversation
Signed-off-by: Kai Fricke <kai@anyscale.com>
Signed-off-by: Kai Fricke <kai@anyscale.com>
Signed-off-by: Kai Fricke <kai@anyscale.com>
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.
Looks good to me! I agree that we should report some metric like % time syncing as part of the release test results in the future.
class AwsDurableTrainable(TestDurableTrainable): | ||
AWS_ACCESS_KEY_ID = aws_key_id | ||
AWS_SECRET_ACCESS_KEY = aws_secret | ||
AWS_SESSION_TOKEN = aws_session |
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.
This stuff is not needed anymore due to propagating the env vars in the runtime env from the previous PR?
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.
That's one thing - the other is that the cluster infrastructure now correctly sets up credentials on all worker nodes
release/tune_tests/scalability_tests/workloads/test_durable_multifile_checkpoints.py
Outdated
Show resolved
Hide resolved
) We are currently only testing single-file checkpoints. However, there have been performance regressions with multi-file checkpoints due to unthreaded uploads in pyarrow. These have since been resolved, but we should collect metrics to catch future regressions. When comparing against a [version where the improvements have been reverted](ray-project#34861), we observe significant improvements in runtime: ``` 2023-04-28 06:52:38,151 INFO tune.py:1011 -- Total run time: 362.95 seconds (337.86 seconds for the tuning loop). ``` vs. ``` 2023-04-28 06:54:57,166 INFO tune.py:1011 -- Total run time: 472.55 seconds (436.54 seconds for the tuning loop). ``` Signed-off-by: Kai Fricke <kai@anyscale.com>
Why are these changes needed?
We are currently only testing single-file checkpoints. However, there have been performance regressions with multi-file checkpoints due to unthreaded uploads in pyarrow. These have since been resolved, but we should collect metrics to catch future regressions.
When comparing against a version where the improvements have been reverted, we observe significant improvements in runtime:
vs.
Related issue number
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.