[
https://issues.apache.org/jira/browse/TEZ-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001681#comment-16001681
]
Eric Badger commented on TEZ-3274:
----------------------------------
[~sseth], in our offline discussion last Thursday, we agreed to remove the
ImmediateStartVertexManager dependency from the RootInputVertexManager and then
implement a new SlowStartVertexManager that the RootInputVertexManager would
extend from. This would solve the MRInput and BROADCAST input problem since
that case uses the RootInputVertexManager. In the interest of not creating
redundant code, I think that it would be a good idea to take the relevant slow
start code out of the ShuffleVertexManager/ShuffleVertexManagerBase and have
ShuffleVertexManagerBase also extend this new SlowStartVertexManager. However,
this would then cause some different functionality for the
ShuffleVertexManagerBase, since the ShuffleVertexManagerBase currently only
uses SCATTER_GATHER edges when computing slow start and the new
SlowStartVertexManager would need to handle both SCATTER_GATHER and BROADCAST.
So I have 2 questions:
1. Should I remove the relevant slow start code from
ShuffleVertexManager/ShuffleVertexManagerBase and have ShuffleVertexManagerBase
extend SlowStartVertexManager
2. If yes, should I compute slow start separately for both SCATTER_GATHER and
BROADCAST or should I just treat all edge types as the same in the computation?
cc [~jeagles]
> Vertex with MRInput and broadcast input does not respect slow start
> -------------------------------------------------------------------
>
> Key: TEZ-3274
> URL: https://issues.apache.org/jira/browse/TEZ-3274
> Project: Apache Tez
> Issue Type: Bug
> Reporter: Jonathan Eagles
> Assignee: Eric Badger
> Attachments: TEZ-3274.001.patch, TEZ-3274.002.patch,
> TEZ-3274.003.patch
>
>
> Vertices with shuffle input and MRInput choose RootInputVertexManager (and
> not ShuffleVertexManager) and start containers and tasks immediately. In this
> scenario, resources can be wasted since they do not respect
> tez.shuffle-vertex-manager.min-src-fraction
> tez.shuffle-vertex-manager.max-src-fraction.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)