Skip to content

Conversation

@carsonwang
Copy link
Contributor

The issue only happens if spark.executor.cores is not set and executor memory is set to a high value.
For example, if we have a worker with 4G and 10 cores and we set spark.executor.memory to 3G, then only 1 core is assigned to the executor. The correct number should be 10 cores.
I've added a unit test to illustrate the issue.

@carsonwang
Copy link
Contributor Author

@andrewor14 , would you mind taking a look at this? This is related to recently changes in #7274 and #7668

@SparkQA
Copy link

SparkQA commented Aug 7, 2015

Test build #40130 has finished for PR 8017 at commit 943cc4c.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@carsonwang
Copy link
Contributor Author

retest this please

@srowen
Copy link
Member

srowen commented Aug 7, 2015

You guys probably understand this better than I, but I don't immediately see why this would change the behavior described in the JIRA. It allows executor scheduling where it didn't before (in the case where no executors are being launched though?) but why does that make more cores get assigned to the executor that's launched? I also couldn't see where the available memory was set to 4g.

@andrewor14
Copy link
Contributor

Great catch!! I believe that was fixed in #7668 but was later introduced again in #7532. Thanks for adding the unit test.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess this is not affected because minCoresPerExecutor is 1 in this case.

@andrewor14
Copy link
Contributor

retest this please. I'm upgrading this to a 1.5 blocker.

Copy link
Contributor

Choose a reason for hiding this comment

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

would you mind rewriting this as follows now that we have more shared code?

val keepScheduling = coresToAssign >= minCoresPerExecutor
val enoughCores = usableWorkers(pos).coresFree - assignedCores(pos) >= minCoresPerExecutor

// If we allow multiple executors per worker, then we can always launch new executors.
// Otherwise, if there is already an executor on this worker, just give it more cores.
val launchingNewExecutor = !oneExecutorPerWorker || assignedExecutors(pos) == 0
if (launchingNewExecutor) {
  val assignedMemory = assignedExecutors(pos) * memoryPerExecutor
  val enoughMemory = usableWorkers(pos).memoryFree - assignedMemory >= memoryPerExecutor
  val underLimit = assignedExecutors.sum + app.executors.size < app.executorLimit
  keepScheduling && enoughCores && enoughMemory && underLimit
} else {
  // We're adding cores to an existing executor, so no need to check memory and executor limits
  keepScheduling && enoughCores
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks great. I'll update it.

@SparkQA
Copy link

SparkQA commented Aug 7, 2015

Test build #40178 has finished for PR 8017 at commit 943cc4c.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Aug 8, 2015

Test build #40219 has finished for PR 8017 at commit 86b651f.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@carsonwang
Copy link
Contributor Author

retest this please.

@SparkQA
Copy link

SparkQA commented Aug 8, 2015

Test build #40220 has finished for PR 8017 at commit d09ec48.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@andrewor14
Copy link
Contributor

LGTM, merging into master and 1.5. Thanks for your fix.

asfgit pushed a commit that referenced this pull request Aug 8, 2015
…cores is not set

The issue only happens if `spark.executor.cores` is not set and executor memory is set to a high value.
For example, if we have a worker with 4G and 10 cores and we set `spark.executor.memory` to 3G, then only 1 core is assigned to the executor. The correct number should be 10 cores.
I've added a unit test to illustrate the issue.

Author: Carson Wang <[email protected]>

Closes #8017 from carsonwang/SPARK-9731 and squashes the following commits:

d09ec48 [Carson Wang] Fix code style
86b651f [Carson Wang] Simplify the code
943cc4c [Carson Wang] fix scheduling correct cores to executors

(cherry picked from commit ef062c1)
Signed-off-by: Andrew Or <[email protected]>
@asfgit asfgit closed this in ef062c1 Aug 8, 2015
@carsonwang carsonwang deleted the SPARK-9731 branch August 17, 2015 01:22
CodingCat pushed a commit to CodingCat/spark that referenced this pull request Aug 17, 2015
…cores is not set

The issue only happens if `spark.executor.cores` is not set and executor memory is set to a high value.
For example, if we have a worker with 4G and 10 cores and we set `spark.executor.memory` to 3G, then only 1 core is assigned to the executor. The correct number should be 10 cores.
I've added a unit test to illustrate the issue.

Author: Carson Wang <[email protected]>

Closes apache#8017 from carsonwang/SPARK-9731 and squashes the following commits:

d09ec48 [Carson Wang] Fix code style
86b651f [Carson Wang] Simplify the code
943cc4c [Carson Wang] fix scheduling correct cores to executors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants