[
https://issues.apache.org/jira/browse/MAPREDUCE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334308#comment-14334308
]
Gera Shegalov commented on MAPREDUCE-4815:
------------------------------------------
Thanks for v14, [~l201514].
Please check the code style again in the whole patch. I think you have some
80-column line width violations in {{mapred.TestFileOutputCommitter}}
Other suggestions:
*mapred-default.xml*
I think it would be useful to document the algorithm 1 before pointing out its
performance problems (mention this JIRA as well). Then document algorithm 2.
*output.FileOutputCommitter*
We can save one RPC roundtrip per commitTask. We have a check {{if
(fs.exists(taskAttemptPath))}} before doing the {{algorithmVersion == 1}}. Then
in case of version 2, we need {{fs.getFileStatus(taskAttemptPath)}}. If you
look at {{FileSystem#exists}} it's implemented using {{getFileStatus}}. Please
use getFileStatus to do the exists check manually such that you don't have to
call it again for the second case.
> FileOutputCommitter.commitJob can be very slow for jobs with many output files
> ------------------------------------------------------------------------------
>
> Key: MAPREDUCE-4815
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4815
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 0.23.3, 2.0.1-alpha, 2.4.1
> Reporter: Jason Lowe
> Assignee: Siqi Li
> Attachments: MAPREDUCE-4815.v10.patch, MAPREDUCE-4815.v11.patch,
> MAPREDUCE-4815.v12.patch, MAPREDUCE-4815.v13.patch, MAPREDUCE-4815.v14.patch,
> MAPREDUCE-4815.v3.patch, MAPREDUCE-4815.v4.patch, MAPREDUCE-4815.v5.patch,
> MAPREDUCE-4815.v6.patch, MAPREDUCE-4815.v7.patch, MAPREDUCE-4815.v8.patch,
> MAPREDUCE-4815.v9.patch
>
>
> If a job generates many files to commit then the commitJob method call at the
> end of the job can take minutes. This is a performance regression from 1.x,
> as 1.x had the tasks commit directly to the final output directory as they
> were completing and commitJob had very little to do. The commit work was
> processed in parallel and overlapped the processing of outstanding tasks. In
> 0.23/2.x, the commit is single-threaded and waits until all tasks have
> completed before commencing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
