[ 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-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org