[ https://issues.apache.org/jira/browse/SPARK-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235015#comment-14235015
]
Aaron Davidson commented on SPARK-4740:
---------------------------------------
To clarify, we have two hypotheses currently:
1. Something is weird about transferTo that actually makes it less efficient than reading
the whole thing into memory in this situation.
2. The fact that we only have 1 connection (and thus serving thread) per peer is causing us
to only concurrently access up to 3 disks at once, though we're not sure if NIO is using more
than 3 threads to serve either.
If we rule out transferTo and it turns out NIO is using more than 3 threads to serve, it is
likely that we should try making TransportClientFactory able to produce more than 1 TransportClient
per host for situations where the number of Executors is much less than the number of cores
per Executor.
> Netty's network throughput is about 1/2 of NIO's in spark-perf sortByKey
> ------------------------------------------------------------------------
>
> Key: SPARK-4740
> URL: https://issues.apache.org/jira/browse/SPARK-4740
> Project: Spark
> Issue Type: Improvement
> Components: Shuffle, Spark Core
> Affects Versions: 1.2.0
> Reporter: Zhang, Liye
> Attachments: Spark-perf Test Report.pdf, TestRunner sort-by-key - Thread dump
for executor 1_files (48 Cores per node).zip
>
>
> When testing current spark master (1.3.0-snapshot) with spark-perf (sort-by-key, aggregate-by-key,
etc), Netty based shuffle transferService takes much longer time than NIO based shuffle transferService.
The network throughput of Netty is only about half of that of NIO.
> We tested with standalone mode, and the data set we used for test is 20 billion records,
and the total size is about 400GB. Spark-perf test is Running on a 4 node cluster with 10G
NIC, 48 cpu cores per node and each executor memory is 64GB. The reduce tasks number is set
to 1000.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org
|