[
https://issues.apache.org/jira/browse/MAPREDUCE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092972#comment-13092972
]
Binglin Chang commented on MAPREDUCE-2841:
------------------------------------------
bq. It might make sense to commit that subset as optional functionality first,
then iterate based on feedback.
I agree. How to contribute this to hadoop? Add a new subdirectory in contrib
like streaming, or merge to native, or stay in current c++/libnativetask?
It contains both c++ and java code, and will likely to add client tools like
streaming, and dev SDK.
Random memory config gives the Resource Scheduler more information so it may
yield better schedule algorithms. As for OOM, there is a flex layer for memory
control already, page cache. In typical slave node memory configuration and
real cases, page cache (should) take considerable proportions of total
memory(20%-50%), so for example tasks can be configured to use 60% of memory,
but can have some variance in 20% range, and the variance become relatively
small when multiple tasks combined to node level or whole job level.
One of my colleague is working on shuffle service, which delegate all reduce
shuffle work to a per node service, this has some aspect which is similar:
For a single task, the variance of memory footprint is a problem, but it gets
much stable for many tasks run on a node.
> Task level native optimization
> ------------------------------
>
> Key: MAPREDUCE-2841
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2841
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: task
> Environment: x86-64 Linux
> Reporter: Binglin Chang
> Assignee: Binglin Chang
> Attachments: MAPREDUCE-2841.v1.patch, dualpivot-0.patch,
> dualpivotv20-0.patch
>
>
> I'm recently working on native optimization for MapTask based on JNI.
> The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs
> emitted by mapper, therefore sort, spill, IFile serialization can all be done
> in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising
> results:
> 1. Sort is about 3x-10x as fast as java(only binary string compare is
> supported)
> 2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware
> CRC32C is used, things can get much faster(1G/s).
> 3. Merge code is not completed yet, so the test use enough io.sort.mb to
> prevent mid-spill
> This leads to a total speed up of 2x~3x for the whole MapTask, if
> IdentityMapper(mapper does nothing) is used.
> There are limitations of course, currently only Text and BytesWritable is
> supported, and I have not think through many things right now, such as how to
> support map side combine. I had some discussion with somebody familiar with
> hive, it seems that these limitations won't be much problem for Hive to
> benefit from those optimizations, at least. Advices or discussions about
> improving compatibility are most welcome:)
> Currently NativeMapOutputCollector has a static method called canEnable(),
> which checks if key/value type, comparator type, combiner are all compatible,
> then MapTask can choose to enable NativeMapOutputCollector.
> This is only a preliminary test, more work need to be done. I expect better
> final results, and I believe similar optimization can be adopt to reduce task
> and shuffle too.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
