Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # user >> io.sort.factor


Hi,

>From my understanding, increasing "io.sort.mb" decreases the number of disk
flushes as more data is spilled at once and this boosts the performance.
This obviously decreases the number of spills.

One possibility in this case is that, the number of spills have become less
than "io.sort.factor" and all the spills are getting merged in a single go
(per partition). So even if you increase the "io.sort.factor" value now, it
shouldn't make any difference. So check the logs and see the no. of spills
created and if its less than "io.sort.factor".

This is a wild guess, please feel free to correct me if I'm wrong.

Thanks

On Wed, Jan 23, 2013 at 11:53 AM, Ajay Srivastava <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> io.sort.factor  --  The number of streams to merge at once while sorting
> files. This determines the number of open file handles.
>
>
> How can I use this parameter to improve performance of mapreduce job?
> My understanding from above description was If there are many spill
> records then increasing io.sort.mb as well as io.sort.factor will help in
> better performance. Increasing io.sort.mb helped but changing
> io.sort.factor (> 10) does not seem to improve/degrade performance of
> mapred  job.
>
>
>
> Regards,
> Ajay Srivastava
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB