[ 
https://issues.apache.org/jira/browse/MAPREDUCE-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934321#comment-13934321
 ] 

Nikola Vujic commented on MAPREDUCE-5791:
-----------------------------------------

I agree about the root cause. I saw that code too. Since I use Oracle JDK, I 
wanted to verify that the native implementation does not exists in Oracle JDK, 
but I couldn't find source code for nio.dll in Oracle JDK. Thus I run the test 
with OpenJDK in order to compare performance and I observed the same behavior. 
So, both JDKs are behaving the same in the shuffle, which means that Oracle JDK 
is also missing native implementation for the zero-copy transfer on Windows 
(assuming that the zero-copy transfer would work at least as fast as buffer 
copy).

It is good idea to try JNI call to TransmitFile. Actually, it may happen to get 
a perf boost from TransmitFile due to a shuffle phase being CPU bound now (CPU 
is at 100% during shuffle with buffer copy). I will have to try it.



> Shuffle phase is slow in Windows - FadviseFileRegion::transferTo does not 
> read disks efficiently
> ------------------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-5791
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5791
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>            Reporter: Nikola Vujic
>            Assignee: Nikola Vujic
>         Attachments: MAPREDUCE-5791.patch
>
>
> transferTo method in org.apache.hadoop.mapred.FadvisedFileRegion is using 
> transferTo method from a FileChannel to transfer data from a disk to socket. 
> This is performing slow in Windows, slower than in Linux. The reason is that 
> transferTo method for the java.nio is issuing 32K IO requests all the time. 
> In Windows, these 32K transfers are not optimal and we don't get the best 
> performance form the underlying IO subsystem. In order to achieve better 
> performance when reading from the drives, we need to read data in bigger 
> chunks, 512K for example.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to