-
Notifications
You must be signed in to change notification settings - Fork 5.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
[release][tune] [build_base] Fix tune_scalability_durable_trainable
configuration to force experiment syncs less often
#31649
[release][tune] [build_base] Fix tune_scalability_durable_trainable
configuration to force experiment syncs less often
#31649
Conversation
Signed-off-by: Justin Yu <[email protected]>
…y_tune_scalability_test
…y_tune_scalability_test
…y_tune_scalability_test
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.
Instead of increasing the number of checkpoints to keep, can we just increase the fake training time? This will also increase the time between checkpoint syncs, correct?
@krfricke Yes, we could increase the training time and increase the test pass threshold. Currently, the fake training time per iteration is 6s. |
@justinvyu I'd prefer that option then, could you update the PR? Thanks! |
Signed-off-by: Justin Yu <[email protected]>
…y_tune_scalability_test
… configuration to force experiment syncs less often (ray-project#31649) Deflakes `tune_scalability_durable_trainable` release test by configuring it so that forced experiment checkpoint syncs happen less frequently, cutting down on the test runtime. Signed-off-by: Justin Yu <[email protected]> Signed-off-by: Andrea Pisoni <[email protected]>
Deflakes
tune_scalability_durable_trainable
release test by configuring it so that forced experiment checkpoint syncs happen less frequently, cutting down on the test runtime.Why are these changes needed?
The
tune_scalability_durable_trainable
test had a performance regression (running for ~300s longer) and is flaky. This was due to experiment checkpoint syncing to cloud being forced more often due to a fix by #31131. Each forced sync causes the driver to wait until that sync is finished before launching a new one, which accounts for the drastically increased runtime. This PR fixes the issue by increasing the number of checkpoints to keep, which in turn reduces the frequency of forced cloud syncs.Question: How can we provide a better default for users? Can we provide a maximum amount of time spent waiting on cloud syncs? So that even if the user configures
keep_checkpoints_num
in such a way that syncs are getting forced very frequently, their script runtime doesn't get affected past a certain amount.Related issue number
Closes #31506
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.