-
Notifications
You must be signed in to change notification settings - Fork 29k
[3.0][SPARK-32518][CORE] CoarseGrainedSchedulerBackend.maxNumConcurrentTasks should consider all kinds of resources #29395
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
Conversation
|
ping @cloud-fan @tgravescs |
| ConfigBuilder("spark.testing.skipValidateCores") | ||
| .version("3.1.0") | ||
| .booleanConf | ||
| .createWithDefault(false) |
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.
These 2 configs are backported from Master branch.
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.
ditto. This should be 3.0.1 when it comes to branch-3.0, @Ngone51 .
Also, after merging this, please update master branch consistently.
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.
Thank you @dongjoon-hyun for letting me know. I was wondering about it previously.
|
Test build #127268 has finished for PR 29395 at commit
|
core/src/main/scala/org/apache/spark/scheduler/TaskSchedulerImpl.scala
Outdated
Show resolved
Hide resolved
| .collect() | ||
| } | ||
| assert(exception.getMessage.contains("[SPARK-24819]: Barrier execution " + | ||
| "mode does not allow run a barrier stage that requires more slots")) |
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.
I'm not sure if its worth it but it would be nice to perhaps print what the limiting resource is. If its to much change or work to track we may just skip it.
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 actually a good idea. But as you mentioned, I'm afraid this needs much more changes. So, I'd like to skip it 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.
ok, we can revisit if it becomes an issue later.
|
Test build #127324 has finished for PR 29395 at commit
|
|
@tgravescs @clockfly Is it looks OK now? |
tgravescs
left a comment
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.
lgtm
| .createWithDefault(2) | ||
|
|
||
| val RESOURCES_WARNING_TESTING = ConfigBuilder("spark.resources.warnings.testing") | ||
| .version("3.1.0") |
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 should be 3.0.1 when it comes to branch-3.0, @Ngone51 .
dongjoon-hyun
left a comment
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.
Please config version properly.
|
Test build #127436 has finished for PR 29395 at commit
|
|
retest this please. |
|
Test build #127442 has finished for PR 29395 at commit
|
|
retest this please |
|
Test build #127450 has finished for PR 29395 at commit
|
|
test this please |
|
Test build #127458 has finished for PR 29395 at commit
|
|
retest this please |
|
Test build #127473 has finished for PR 29395 at commit
|
|
retest this please. |
|
Test build #127496 has finished for PR 29395 at commit
|
|
|
|
retest this please. |
|
Seems like we need to wait for this fix: #29448 |
|
Test build #127498 has finished for PR 29395 at commit
|
9c18479 to
daa205d
Compare
|
Test build #127519 has finished for PR 29395 at commit
|
|
thanks, merging to 3.0! |
…ntTasks should consider all kinds of resources ### What changes were proposed in this pull request? 1. Make `CoarseGrainedSchedulerBackend.maxNumConcurrentTasks()` considers all kinds of resources when calculating the max concurrent tasks 2. Refactor `calculateAvailableSlots()` to make it be able to be used for both `CoarseGrainedSchedulerBackend` and `TaskSchedulerImpl` ### Why are the changes needed? Currently, `CoarseGrainedSchedulerBackend.maxNumConcurrentTasks()` only considers the CPU for the max concurrent tasks. This can cause the application to hang when a barrier stage requires extra custom resources but the cluster doesn't have enough corresponding resources. Because, without the checking for other custom resources in `maxNumConcurrentTasks`, the barrier stage can be submitted to the `TaskSchedulerImpl`. But the `TaskSchedulerImpl` won't launch tasks for the barrier stage due to the insufficient task slots calculated by `TaskSchedulerImpl.calculateAvailableSlots` (which does check all kinds of resources). If the barrier stage doesn't launch all the tasks in one true, the application will fail and suggest user to disable delay scheduling. However, this actually a misleading suggestion since the real root cause is not enough resources. ### Does this PR introduce _any_ user-facing change? Yes. In case of a barrier stage requires more custom resources than the cluster has, previously, the application will fail with misleading suggestion of disabling delay scheduling. After this PR, the application will fail with the error message saying not enough resources. ### How was this patch tested? Added a unit test. Closes #29395 from Ngone51/backport-spark-32518. Authored-by: yi.wu <yi.wu@databricks.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>
What changes were proposed in this pull request?
Make
CoarseGrainedSchedulerBackend.maxNumConcurrentTasks()considers all kinds of resources when calculating the max concurrent tasksRefactor
calculateAvailableSlots()to make it be able to be used for bothCoarseGrainedSchedulerBackendandTaskSchedulerImplWhy are the changes needed?
Currently,
CoarseGrainedSchedulerBackend.maxNumConcurrentTasks()only considers the CPU for the max concurrent tasks. This can cause the application to hang when a barrier stage requires extra custom resources but the cluster doesn't have enough corresponding resources. Because, without the checking for other custom resources inmaxNumConcurrentTasks, the barrier stage can be submitted to theTaskSchedulerImpl. But theTaskSchedulerImplwon't launch tasks for the barrier stage due to the insufficient task slots calculated byTaskSchedulerImpl.calculateAvailableSlots(which does check all kinds of resources).If the barrier stage doesn't launch all the tasks in one true, the application will fail and suggest user to disable delay scheduling. However, this actually a misleading suggestion since the real root cause is not enough resources.
Does this PR introduce any user-facing change?
Yes. In case of a barrier stage requires more custom resources than the cluster has, previously, the application will fail with misleading suggestion of disabling delay scheduling. After this PR, the application will fail with the error message saying not enough resources.
How was this patch tested?
Added a unit test.