[
https://issues.apache.org/jira/browse/MAPREDUCE-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113450#comment-16113450
]
Ravi Prakash commented on MAPREDUCE-6923:
-----------------------------------------
Thank you for the contribution Robert. You are right that the typecast inside
{{Math.min()}} would be wrong. I was thinking outside the Math.min() would be
fine like in your {{testCast}} . In either case, I agree its alright to keep
the ternary operator there for clarity and in case shuffleBufferSize is ever
incorrectly configured to be negative.
Thank you for that wonderful analysis. It is very valuable.
bq. YARN reads a total of 1169 GiB in my setup
How are you measuring that? Does this take into account the jar files that the
MapTask and ReduceTask must read to start the JVM? On some installations I've
seen the JVM load close to 400Mb of jar files for hadoop and its dependencies.
Even on trunk my MapTask reads about 180Mb of jars atleast.
I'm sure "Failed Shuffles" would be executed again. I don't know where the
failure would be picked up from, but its probably from the beginning. This is
possibly due to your network.
Thanks for the extensive research.
> YARN Shuffle I/O for small partitions
> -------------------------------------
>
> Key: MAPREDUCE-6923
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6923
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Environment: Observed in Hadoop 2.7.3 and above (judging from the
> source code of future versions), and Ubuntu 16.04.
> Reporter: Robert Schmidtke
> Assignee: Robert Schmidtke
> Attachments: MAPREDUCE-6923.00.patch
>
>
> When a job configuration results in small partitions read by each reducer
> from each mapper (e.g. 65 kilobytes as in my setup: a
> [TeraSort|https://github.com/apache/hadoop/blob/branch-2.7.3/hadoop-mapreduce-project/hadoop-mapreduce-examples/src/main/java/org/apache/hadoop/examples/terasort/TeraSort.java]
> of 256 gigabytes using 2048 mappers and reducers each), and setting
> {code:xml}
> <property>
> <name>mapreduce.shuffle.transferTo.allowed</name>
> <value>false</value>
> </property>
> {code}
> then the default setting of
> {code:xml}
> <property>
> <name>mapreduce.shuffle.transfer.buffer.size</name>
> <value>131072</value>
> </property>
> {code}
> results in almost 100% overhead in reads during shuffle in YARN, because for
> each 65K needed, 128K are read.
> I propose a fix in
> [FadvisedFileRegion.java|https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle/src/main/java/org/apache/hadoop/mapred/FadvisedFileRegion.java#L114]
> as follows:
> {code:java}
> ByteBuffer byteBuffer = ByteBuffer.allocate(Math.min(this.shuffleBufferSize,
> trans > Integer.MAX_VALUE ? Integer.MAX_VALUE : (int) trans));
> {code}
> e.g.
> [here|https://github.com/apache/hadoop/compare/branch-2.7.3...robert-schmidtke:adaptive-shuffle-buffer].
> This sets the shuffle buffer size to the minimum value of the shuffle buffer
> size specified in the configuration (128K by default), and the actual
> partition size (65K on average in my setup). In my benchmarks this reduced
> the read overhead in YARN from about 100% (255 additional gigabytes as
> described above) down to about 18% (an additional 45 gigabytes). The runtime
> of the job remained the same in my setup.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
