TeraSort实验--测试Map和Reduce Task数量对Hadoop性能的影响

一、           实验环境

1个master节点, 16个slave节点: CPU:8GHZ , 内存: 2G

网络：局域网

二、           实验描述

   通过Hadoop自带的Terasort排序程序，测试不同的map task和reduce task数量，对Hadoop性能的影响。

   实验数据由程序中的teragen程序生成，数据量为1GB和10GB。

   通过设置mapred.min.split.size，从而调节map task的数量；设置mapred.reduce.tasks，从而调节reduce task的数量；

   dfs.replication的值设为3，其它参数默认。

三、           实验结果与分析

Ø  实验一

                表1、改变reduce task（数据量为1GB)

结果分析：

1)         当reduce task的值小于15时，总时间和Reduce时间都与Reduce task数量成反比关系。当reduce task的值大于15时，总时间和reduce时间基本保持恒定。Reduce task的数量应该设置为接近slave节点数量，或者适当大于节点数，不宜设置为比节点数量小太多。

2)         Map时间与Reduce task之间没有明显的关系。

3)         Killed map Task Attempts的值对Map的时间影响很大，表1中当reduce task = 45时，Killed map Task Attempts的值为1，此时Map的时间很长，从图1可看出，map的时间主要集中在map 99%的最后阶段。

4)         job运行过程中产生Killed Task Attempts的原因：这是因为hadoop里面对task的speculative机制。简单来说就是hadoop觉得有些task运行过慢，所以它在其它tasktracker上同时再运行同样的任务，当其中一个完成后，其余同样的任务就会被kill掉。这就造成有多个被kill的taskattempt。可以通过设置mapred.map.tasks.speculative.execution为false来禁止hadoop的这种行为，这样可以提高效率，因为每个speculative都是占用task的slot的。

图1、表1中当reduce task = 45的执行过程

Ø  实验二

          表2 改变reduce task(数据量为1GB)

图2、 1G数据性能对比

                        表3 改变map task(数据量为10GB)

图2、 10G数据性能对比

结果分析：

1)         Map Task数量对系统性能有很大影响。1G数据时，最差性能(372秒)比最好性能(120秒)低三倍，10G数据时，最差性能(3044秒)比最好性能(2189秒)多了大约14分钟。

2)         当数据量为1G和10时，总时间、Map时间、Shuffle时间、Reduce时间随着Map task数量的增大，总体上均呈现先减小后增大的变化趋势；

3)         当数据量为1G和10G时，把Input Split Size设置为128M(此时，1G数据Map task=8, 10G数据Map task =76),系统性能最佳；

当数据量为1G时，Failed的task数量一直都是0，然而当数据量为10G时，Failed task的数量变大很多，分析后发现是，数据量增大后，因为某些节点硬盘剩余容量较小，导致Fail。

本文原创，转载请注明，谢谢。

本文地址http://blog.csdn.net/xiejava/archive/2011/05/19/6432095.aspx