[
https://issues.apache.org/jira/browse/SPARK-15176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311035#comment-15311035
]
Imran Rashid commented on SPARK-15176:
--------------------------------------
late to the party, but I support the feature too. I've seen similar use cases
from a number of users, just most haven't gotten sophisticated enough with
their deployments to care about this yet (but they probably will soon).
I am still concerned about the what the right api is. Do we want {{maxShare}}
or {{maxRunningTasks}}? I don't want to add {{maxRunningTasks}} just because
its easier to implement, but then we are stuck with the wrong api later on.
(I'm actually not sure I prefer {{maxShare}}, I think I need more time to think
about it before I have a strong opinion ... or if somebody else can make a case
one way or the other.)
> Job Scheduling Within Application Suffers from Priority Inversion
> -----------------------------------------------------------------
>
> Key: SPARK-15176
> URL: https://issues.apache.org/jira/browse/SPARK-15176
> Project: Spark
> Issue Type: Bug
> Components: Scheduler
> Affects Versions: 1.6.1
> Reporter: Nick White
>
> Say I have two pools, and N cores in my cluster:
> * I submit a job to one, which has M >> N tasks
> * N of the M tasks are scheduled
> * I submit a job to the second pool - but none of its tasks get scheduled
> until a task from the other pool finishes!
> This can lead to unbounded denial-of-service for the second pool - regardless
> of `minShare` or `weight` settings. Ideally Spark would support a pre-emption
> mechanism, or an upper bound on a pool's resource usage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
