Skip to content

[SPARK-18981][Core]The job hang problem when speculation is on - #16389

Closed
zhaorongsheng wants to merge 2 commits into
apache:masterfrom
zhaorongsheng:master
Closed

[SPARK-18981][Core]The job hang problem when speculation is on#16389
zhaorongsheng wants to merge 2 commits into
apache:masterfrom
zhaorongsheng:master

Conversation

@zhaorongsheng

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

The root cause of this issue is that ExecutorAllocationListener gets the speculated task end info after the stage end event handling which let numRunningTasks = 0. Then it let numRunningTasks -= 1 so the #numRunningTasks is negative. When calculate #maxNeeded in method maxNumExecutorsNeeded(), the value may be 0 or negative. So ExecutorAllocationManager does not request container and the job will be hung.

This PR changes the method onTaskEnd() in ExecutorAllocationListener. When stageIdToNumTasks contains the taskEnd's stageId, let #numRunningTasks minus 1.

How was this patch tested?

This patch was tested in the method test("SPARK-18981...) of ExecutorAllocationManagerSuite.scala.
Create two taskInfos and one of them is speculated task. After the stage ending event, the speculated task ending event is posted to listener.

@mridulmmridulm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

While I dont think the change itself might be incorrect : did you see
'No stages are running, but numRunningTasks != 0' in the logs ?

val taskInfo = createTaskInfo(1, 1, "executor-1")
val speculatedTaskInfo = createTaskInfo(2, 1, "executor-1")
sc.listenerBus.postToAll(SparkListenerTaskStart(0, 0, taskInfo))
assert(maxNumExecutorsNeeded(manager) === 1)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This tests looks wrong - taskIndex is higher than numTasks ?
Would be better for the test to :

  • Launch stage with 1 task.
  • Launch a normal task and 1 speculative task - with same taskIndex, but different taskId's
  • Finish normal task.
  • Ensure stage is completed.
  • Now finish speculative task and check if bug is not reproduced (it should be reproduced without this fix).

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Yes, the warning info 'No stages are running, but numRunningTasks != 0' is printed and at that time the #numRunningTasks is set to 0. But after that the speculated task end event is arrived and the #numRunningTasks will plus 1.
The tests are wrong, I will fix it.

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

Hi @mridulm . I have modified the tests. Please check it.
Thanks~

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

Jenkins, retest this please

@mridulm

mridulm commented Dec 24, 2016

Copy link
Copy Markdown
Contributor

Does it fail in master without the fix ?

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

Yes, I have checked it.

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

@mridulm Please check it. Thanks~

@zhaorongsheng

zhaorongsheng commented Dec 28, 2016

Copy link
Copy Markdown
ContributorAuthor

Hi, can anyone check this PR?
thanks

@zsxwing

Copy link
Copy Markdown
Member

Can we just not reset numRunningTasks to 0? I think it should include speculative tasks and we can add a comment about it.

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

@zsxwing I think it may cause some other problem.
For example, if we got some ExecutorLostFailure and the speculated task was running on it, the numRunningTasks will never be zero.

@zhaorongsheng

Copy link
Copy Markdown
ContributorAuthor

@zsxwing@mridulm
Would you check this PR please?

Thanks~

@jinxing64

Copy link
Copy Markdown

@zhaorongsheng
I think its better to just not reset numRunningTasks to 0. If we got some ExecutorLostFailure, the stage should not be marked as finished.

@HyukjinKwon

Copy link
Copy Markdown
Member

@zhaorongsheng, is this still active and any opinion on ^?

@HyukjinKwonHyukjinKwon mentioned this pull request May 17, 2017
zifeif2 pushed a commit to zifeif2/spark that referenced this pull request Nov 22, 2025
## What changes were proposed in this pull request?
This PR proposes to close PRs ...
- inactive to the review comments more than a month
- WIP and inactive more than a month
- with Jenkins build failure but inactive more than a month
- suggested to be closed and no comment against that
- obviously looking inappropriate (e.g., Branch 0.5)
To make sure, I left a comment for each PR about a week ago and I could not have a response back from the author in these PRs below:
Closesapache#11129Closesapache#12085Closesapache#12162Closesapache#12419Closesapache#12420Closesapache#12491Closesapache#13762Closesapache#13837Closesapache#13851Closesapache#13881Closesapache#13891Closesapache#13959Closesapache#14091Closesapache#14481Closesapache#14547Closesapache#14557Closesapache#14686Closesapache#15594Closesapache#15652Closesapache#15850Closesapache#15914Closesapache#15918Closesapache#16285Closesapache#16389Closesapache#16652Closesapache#16743Closesapache#16893Closesapache#16975Closesapache#17001Closesapache#17088Closesapache#17119Closesapache#17272Closesapache#17971
Added:
Closesapache#17778Closesapache#17303Closesapache#17872
## How was this patch tested?
N/A
Author: hyukjinkwon <gurwls223@gmail.com>
Closesapache#18017 from HyukjinKwon/close-inactive-prs.
Sign up for freeto 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.

5 participants

@zhaorongsheng@mridulm@zsxwing@jinxing64@HyukjinKwon