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)

Map task = 16
Reduce task	1	5	10	15	16	20	25	30	45	60
总时间	892	146	110	92	88	100	128	101	145	104
Map 时间	24	21	25	50	21	40	24	48	109	25
Reduce时间	875	125	88	71	67	76	102	80	98	83
Killed map/reduce Task Attempts	0/0	0/2	0/2	0/5	0/4	0/9	0/9	0/8	1/7	0/17

结果分析：
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)

Reduce task = 15
Map task	2	4	8	16
Input Split Size	512	256	128	64
总时间	372	181	120	120
平均 Map 时间	287	63	38	26
Map结束时间	292	49	35	36
平均Shuffle时间	12	42	28	45
Shuffle结束时间	308	103	63	67
平均Reduce时间	30	34	37	28
Reduce结束时间	343	154	113	100
Killed map/reduce Task Attempts	0/4	0/5	0/3	0/5

图2、 1G数据性能对比

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

Reduce task = 15
Map task	20	38	76	150
Input Split Size	512	256	128	64
总时间	3044	2464	2189	2362
平均 Map 时间	1274	825	403	231
Map结束时间	1712	1409	1061	1268
平均Map时间	1800	1300	1144	1198
Shuffle结束时间	2271	2236	1804	2059
平均Reduce时间	515	450	548	644
Reduce结束时间	2624	2453	2181	2348
Map Failed/Killed Task Attempts	4/8	5/7	6/7	7/8
Reduce Failed/Killed Task Attempts	2/3	3/1	3/1	2/1

图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