学步园

被测软件： yahoo-hadoop-0.20.1-3041192000  & Terasort

 测试环境：

 操作系统:CentOS 5.2

硬件平台:1路4核XEON 2.5G/8G内存/4*250G SATA 7.2K硬盘

 测试说明：

以TeraSort为例，通过节点规模N、平均每节点处理的数据量DPN（GB）和总数据量D（GB） 3个维度来分析mapreduce系统的性能。

相关参数如下表：

其中，P代表的平均每节点的实际处理能力=平均每节点处理的数据量DPN/作业执行时间

 测试结果：

 =>固定N，调整DPN，得到该N值下最优的DPN

图1   N=32时，P与DPN关系图

 在节点规模为32的时候，调整输入数据量的大小，使得平均每节点处理的数据量DPN分别为0.5、1、2、3、4、5、6，测试结果显示平均每节点的实际处理能力在DPN为0.5和2的时候性能较好，明显好于其他值的时候 (DPN=2GB时有一个跳变，未发现原因)。

在节点规模为64的时候，调整输入数据量的大小，使得平均每节点处理的数据量DPN分别为0.5、1、2、3、4、5、6，测试结果显示，与节点规模N=32的情况相似，平均每节点的实际处理能力在DPN为0.5的时候性能较好，明显好于其他值的时候。

 => 固定DPN，调整N，得到该DPN下最合适的N

图3  DPN=0.5时，P与N关系图

 调整节点规模N分别为16、32、64，选择合适的输入数据量，使得平均每节点处理的数据量DPN保持为0.5，测试结果显示，节点规模为16的时候平均每节点的实际处理能力最好。

图4  DPN=2时，P与N关系图

调整节点规模N分别为16、32、64，选择合适的输入数据量，使得平均每节点处理的数据量DPN保持为0.5，测试结果显示，节点规模为16的时候平均每节点的实际处理能力最好。

=>    固定D，调整N，得到该D下最合适的N

图5  D=96GB时，P与DPN关系图

固定输入数据量为96GB，调整节点规模N，使得平均每节点处理的数据量DPN分别为1.5、3、6，测试结果显示DPN=6的时候平均每节点的实际处理能力最好。

结果分析：

 1.对于固定N、调整DPN的情况，随着DPN的变大，即每个节点处理的数据量的增加，会使得整个作业map个数的增加，测试中看到各种DPN下每个map的平均时间变化不大，而map的总时间会越来越长；而在reduce阶段，由于总的reduce个数是读取的配置文件，各个DPN时该个数相同，所以平均每个reduce任务将要拷贝更多的map输出结果，造成shuffle和reduce时间也变长，最终势必会延长作业的总的执行时间。所以在该情况下，DPN在较小的0.5时，性能较好。

 2.对于固定DPN、调整N的情况，随着N的变大，若要保持DPN不变，总数据量D必然增加，这使得总的map任务个数随之增加，但是平均每个节点处理的map任务个数不变，使得map阶段的时间基本保持不变；而在reduce阶段，由于总的reduce个数是读取的配置文件，reduce任务个数是相同的，平均每个reduce任务将要拷贝更多的map输出结果，造成shuffle和reduce时间也变长，总的执行时间也就变长了。所以在该情况下，N在较小的16时，性能较好。

经过上面的分析，建议在测试中，可以在配置文件mapred-site.xml中将参数mapred.reduce.tasks按照节点规模成比例变化，使得在各种节点规模下，执行作业时平均每个节点分配的reduce任务都相同，从而使得各个reduce任务平均拷贝的map输出结果保持不变，进而得出的测试结果更具说服力，即可按照下表的设置：

3.对于固定D、调整N的情况，由于总的数据量保持不变，则map任务数是恒定不变的，随着节点规模N的增加，平均每个节点的map任务数减少，整个map阶段时间减短；在reduce阶段，由于reduce个数相同，使得平均每个reduce任务拷贝的map结果也相同，reduce阶段的时间受map结果产生快慢的影响，从而使得总的执行时间随着节点规模的变大而变短。但是由于平均每节点的实际处理能力除了与时间长短有关，还与DPN有关，从测试结果来看，DPN缩小一半后，执行时间并没有相应的缩小到一半，而是大于一半，使得计算出的平均每节点的实际处理能力在N=16时最优，即节点规模的变大，并没有导致作业的执行时间成比例线性缩短，详细情况如下表：

关于测试结果准确性的说明：

 由于此次测试结果对hadoop的系统配置参数未做优化，特别是在不同节点规模中均设置了16个reduceTask，所以有些测试结果不是很准确。

博客链接：http://labs.chinamobile.com/mblog/227_63741