Skip to content
This repository has been archived by the owner on Jan 9, 2020. It is now read-only.

Allow number of executor cores to have fractional values #361

Merged
merged 1 commit into from
Jun 29, 2017
Merged

Allow number of executor cores to have fractional values #361

merged 1 commit into from
Jun 29, 2017

Conversation

liyinan926
Copy link
Member

This commit tries to solve issue #359 by allowing the spark.executor.cores configuration key to take fractional values, e.g., 0.5 or 1.5. The value is used to specify the cpu request when creating the executor pods, which is allowed to be fractional by Kubernetes. When the value is passed to the executor process through the environment variable SPARK_EXECUTOR_CORES, the value is rounded up to the closest integer as expected by the CoarseGrainedExecutorBackend. I expect most use cases of this are to use a fractional of 1 CPU core, e.g., 0.1 or 0.5.

Signed-off-by: Yinan Li [email protected]

@@ -388,7 +388,8 @@ private[spark] class KubernetesClusterSchedulerBackend(
val requiredEnv = Seq(
(ENV_EXECUTOR_PORT, executorPort.toString),
(ENV_DRIVER_URL, driverUrl),
(ENV_EXECUTOR_CORES, executorCores),
// Executor backend expects integral value for executor cores, so round it up to an int.
(ENV_EXECUTOR_CORES, math.ceil(executorCores.toDouble).toInt.toString),
Copy link
Member

@foxish foxish Jun 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could make it a double when we fetch it in KubernetesClusterSchedulerBackend#L110. That can be replaced by conf.getDouble(..., 1.0)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@foxish
Copy link
Member

foxish commented Jun 29, 2017

LGTM except for that one comment.
Thanks @liyinan926

This commit tries to solve issue #359 by allowing the `spark.executor.cores` configuration key to take fractional values, e.g., 0.5 or 1.5. The value is used to specify the cpu request when creating the executor pods, which is allowed to be fractional by Kubernetes. When the value is passed to the executor process through the environment variable `SPARK_EXECUTOR_CORES`, the value is rounded up to the closest integer as required by the `CoarseGrainedExecutorBackend`.

Signed-off-by: Yinan Li <[email protected]>
@liyinan926
Copy link
Member Author

Thanks @foxish for reviewing!

@foxish foxish merged commit 6f6cfd6 into apache-spark-on-k8s:branch-2.1-kubernetes Jun 29, 2017
foxish pushed a commit that referenced this pull request Jul 24, 2017
This commit tries to solve issue #359 by allowing the `spark.executor.cores` configuration key to take fractional values, e.g., 0.5 or 1.5. The value is used to specify the cpu request when creating the executor pods, which is allowed to be fractional by Kubernetes. When the value is passed to the executor process through the environment variable `SPARK_EXECUTOR_CORES`, the value is rounded up to the closest integer as required by the `CoarseGrainedExecutorBackend`.

Signed-off-by: Yinan Li <[email protected]>
ifilonenko pushed a commit to ifilonenko/spark that referenced this pull request Feb 26, 2019
puneetloya pushed a commit to puneetloya/spark that referenced this pull request Mar 11, 2019
…k-on-k8s#361)

This commit tries to solve issue apache-spark-on-k8s#359 by allowing the `spark.executor.cores` configuration key to take fractional values, e.g., 0.5 or 1.5. The value is used to specify the cpu request when creating the executor pods, which is allowed to be fractional by Kubernetes. When the value is passed to the executor process through the environment variable `SPARK_EXECUTOR_CORES`, the value is rounded up to the closest integer as required by the `CoarseGrainedExecutorBackend`.

Signed-off-by: Yinan Li <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants