[jira] [Comment Edited] (SPARK-12554) Standalone app scheduler will hang when app.coreToAssign < minCoresPerExecutor

["Lijie Xu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SPARK-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074543#comment-15074543 ] 

Lijie Xu edited comment on SPARK-12554 at 12/30/15 2:11 AM:
------------------------------------------------------------

I agree that it is a design problem. {{spark.scheduler.maxRegisteredResourcesWaitingTime}} is a powerful parameter, but it still suffers from two problems.
 
(1) Although case 2 is rare, it cannot be resolved by {{spark.scheduler.maxRegisteredResourcesWaitingTime}}. The reason is that {{keepScheduling}} is FALSE at the first time of allocation and no executor will be allocated (i.e., canLaunchExecutor) to the app even the cluster has enough cores.

(2) {{spark.scheduler.maxRegisteredResourcesWaitingTime}} can resolve case 1. However, The app needs to wait 30s and then wait for reusing the executor whose tasks have finished. As a result, the app's performance is not very well.

The dilemma is that whether we should allocate a new executor to the *extra* cores (i.e., {{spark.cores.max % spark.executor.cores}}). Maybe we can design a flexible algorithm for the tradeoff between performance and resources. For example, if {{extra cores / spark.executor.cores >= 0.75}} or {{spark.executor.cores <= 8}}, we can allocate a new executor to the app.


was (Author: jerrylead):
I agree that it is a design problem. {{spark.scheduler.maxRegisteredResourcesWaitingTime}} is a powerful parameter, but it still suffers from two problems.
 
(1) Although case 2 is rare, it cannot be resolved by {{spark.scheduler.maxRegisteredResourcesWaitingTime}}. The reason is that {{keepScheduling}} is FALSE at the first time of allocation and no executor will be allocated (i.e., canLaunchExecutor) to the app even the cluster has enough cores.

(2) {{spark.scheduler.maxRegisteredResourcesWaitingTime}} can resolve case 1. However, The app needs to wait 30s and then wait for reusing the executor whose tasks have finished. As a result, the app's performance is not very well.

The dilemma is that whether we should allocate a new executor to the *extra* cores (i.e., {{spark.cores.max % spark.executor.cores}}). Maybe we can design a flexible algorithm for the tradeoff between performance and resources. For example, if {{extra cores / spark.executor.cores >= 0.75}} or {{spark.executor.cores <= 8}, we can allocate a new executor to the app.

> Standalone app scheduler will hang when app.coreToAssign < minCoresPerExecutor
> ------------------------------------------------------------------------------
>
>                 Key: SPARK-12554
>                 URL: https://issues.apache.org/jira/browse/SPARK-12554
>             Project: Spark
>          Issue Type: Bug
>          Components: Deploy, Scheduler
>    Affects Versions: 1.5.2
>            Reporter: Lijie Xu
>
> In scheduleExecutorsOnWorker() in Master.scala,
> {{val keepScheduling = coresToAssign >= minCoresPerExecutor}} should be changed to {{val keepScheduling = coresToAssign > 0}}
> Case 1: 
> Suppose that an app's requested cores is 10 (i.e., {{spark.cores.max = 10}}) and app.coresPerExecutor is 4 (i.e., {{spark.executor.cores = 4}}). 
> After allocating two executors (each has 4 cores) to this app, the {{app.coresToAssign = 2}} and {{minCoresPerExecutor = coresPerExecutor = 4}}, so {{keepScheduling = false}} and no extra executor will be allocated to this app. If {{spark.scheduler.minRegisteredResourcesRatio}} is set to a large number (e.g., > 0.8 in this case), the app will hang and never finish.
> Case 2: if a small app's coresPerExecutor is larger than its requested cores (e.g., {{spark.cores.max = 10}}, {{spark.executor.cores = 16}}), {{val keepScheduling = coresToAssign >= minCoresPerExecutor}} is always FALSE. As a result, this app will never get an executor to run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org