[
https://issues.apache.org/jira/browse/SPARK-22765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292594#comment-16292594
]
Thomas Graves commented on SPARK-22765:
---------------------------------------
I'm not sure how mr style and 4-core executor go together. either way if you
are allocated executors with 4 cores and only assigning 4 tasks to it (like mr
style) , 3 of those tasks might finish quickly while one last much longer and
you waste resources.
How does MR style solve scheduler inefficiencies? one way or another you have
to schedule tasks to containers you get. Seems like a scheduler issue not a
container allocation issue and this would apply to both schemes unless you
happen to get lucky in that perhaps its not as busy to schedule up front, but
that is going to depend on when you get containers. If you want to investigate
this to improve that would be great.
I'm not really sure what this proposal does that you can't do now (with
SPARK-21656) other then kill an executor after running X tasks rather then wait
for idle. This might be useful but again might hurt you especially in busy
clusters where you might only get a percentage of your executors up front. Let
me know if I'm missing something in your proposal though.
Note that we saw a significant increase in cluster utilization (meaning we were
better usage resources not wasting them) when we moved to pig on tez with
container re-use vs single container MR style. Some of this was due to not
having to do multiple jobs, some was the container reuse. This was across a
cluster though with mixed workloads. I would expect container reuse on spark
to do the same, but there are obviously specialized workloads.
Let me know what you find with SPARK-21656 and if its not sufficient please add
more specifics (design) on what you propose to change.
> Create a new executor allocation scheme based on that of MR
> -----------------------------------------------------------
>
> Key: SPARK-22765
> URL: https://issues.apache.org/jira/browse/SPARK-22765
> Project: Spark
> Issue Type: Improvement
> Components: Scheduler
> Affects Versions: 1.6.0
> Reporter: Xuefu Zhang
>
> Many users migrating their workload from MR to Spark find a significant
> resource consumption hike (i.e, SPARK-22683). While this might not be a
> concern for users that are more performance centric, for others conscious
> about cost, such hike creates a migration obstacle. This situation can get
> worse as more users are moving to cloud.
> Dynamic allocation make it possible for Spark to be deployed in multi-tenant
> environment. With its performance-centric design, its inefficiency has also
> unfortunately shown up, especially when compared with MR. Thus, it's believed
> that MR-styled scheduler still has its merit. Based on our research, the
> inefficiency associated with dynamic allocation comes in many aspects such as
> executor idling out, bigger executors, many stages (rather than 2 stages only
> in MR) in a spark job, etc.
> Rather than fine tuning dynamic allocation for efficiency, the proposal here
> is to add a new, efficiency-centric scheduling scheme based on that of MR.
> Such a MR-based scheme can be further enhanced and be more adapted to Spark
> execution model. This alternative is expected to offer good performance
> improvement (compared to MR) still with similar to or even better efficiency
> than MR.
> Inputs are greatly welcome!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
