[ 
https://issues.apache.org/jira/browse/TEZ-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

László Bodor updated TEZ-4130:
------------------------------
    Description: 
During the investigation of a customer issue, I found that tez generated a dag 
plan containing >4k tasks. It failed for hive because of bucket size 
limitations (4k). It can be configured properly, e.g. bigger splits 
(tez.grouping.min-size), but maybe it would be more convenient for users to 
config a hard limit for shuffle vertex manager.

However, I'm not really sure if it's correct to force changing the max task 
parallelism after split generation already happened (e.g. HiveSplitGenerator):
https://github.com/apache/tez/blob/master/tez-runtime-library/src/main/java/org/apache/tez/dag/library/vertexmanager/ShuffleVertexManager.java#L477


  was:During the investigation of a customer issue, I found that tez generated 
a dag plan containing >4k tasks. It failed for hive because of bucket size 
limitations (4k). However, it can be configured properly, e.g. bigger splits 
(tez.grouping.min-size), it would be more convenient for users to config a hard 
limit for shuffle vertex manager...


> Config for max task parallelism in shuffle - 
> tez.shuffle-vertex-manager.max-task-parallelism
> --------------------------------------------------------------------------------------------
>
>                 Key: TEZ-4130
>                 URL: https://issues.apache.org/jira/browse/TEZ-4130
>             Project: Apache Tez
>          Issue Type: Improvement
>            Reporter: László Bodor
>            Assignee: László Bodor
>            Priority: Major
>
> During the investigation of a customer issue, I found that tez generated a 
> dag plan containing >4k tasks. It failed for hive because of bucket size 
> limitations (4k). It can be configured properly, e.g. bigger splits 
> (tez.grouping.min-size), but maybe it would be more convenient for users to 
> config a hard limit for shuffle vertex manager.
> However, I'm not really sure if it's correct to force changing the max task 
> parallelism after split generation already happened (e.g. HiveSplitGenerator):
> https://github.com/apache/tez/blob/master/tez-runtime-library/src/main/java/org/apache/tez/dag/library/vertexmanager/ShuffleVertexManager.java#L477



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to