-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-2387][Core]Remove Stage's barrier #3430
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
|
Test build #23784 has started for PR 3430 at commit
|
|
Test build #23784 has finished for PR 3430 at commit
|
|
Test FAILed. |
|
Test build #23785 has started for PR 3430 at commit
|
|
Test build #23785 has finished for PR 3430 at commit
|
|
Test FAILed. |
|
Test build #23786 has started for PR 3430 at commit
|
|
Test build #23786 has finished for PR 3430 at commit
|
|
Test FAILed. |
|
Test build #23788 has started for PR 3430 at commit
|
|
Test build #23788 has finished for PR 3430 at commit
|
|
Test PASSed. |
|
This seems like a complicated change for only a 10% performance improvement, especially when there's probably lower-hanging fruit that's easier / safer to optimize. |
|
@JoshRosen i think when we need this feature, we just set spark.scheduler.removeStageBarrier=true and then own this performance improvement. it is important that will not affect other's features. |
|
I'd propose to close this issue. It's a fairly large change and needs more discussion before being seriously considered to be part of spark. |
based on #1328.
when one task of parent stage is not finished, so other executors is idle. we can pre-start the reduce stage to make good use of these idle executors.
This can achieve better resource utilization and improve the overall job performance, especially when there're lots of executors granted to the application.in my no-cache application's test, it improves the job by about 10%.
@lirui-intel @sryza @rxin