MapReduce:Job性能调优总结

是时候把去年早期MapReduce调优工作的结果放出来了，丢在Google Doc里太长时间，都落了一身的灰

Benchmark: 对1G数据做wordcount
部分内容:
*********************************
[b]硬件级别[/b]
[color=orange]提高磁盘IO的性能[/color]
noatime 我为两台slaves server设置了noatime. vi /etc/fstab.map task的平均执行时间减少两秒,这影响硬盘IO的性能,shuffle的时间也相应地减少了1分钟,不影响reduce的执行时间


[b]client端设置[/b]
[color=orange]map与reduce task数量[/color]
map task的数量由split的数量决定,split的数据越小,每个map task执行的时间就越短,但相应地, job的执行时间就拉长了, 因为内部调度的时间更长了
benchmark:
之前是67个map task,平均执行时间是16秒, job完成时间接近7分钟
后来map task变成265个, 平均每个map task执行8秒,但job完成时间差不多12分钟

[color=orange]reduce task的数量由client来设置[/color]
我测试的结果client设置result task略大于或等于集群reduce slot, 当然这是整个集群只有一个job在执行的情况下,当有多个job执行时, 网上的建议是少于集群reduce slots总量
集群reduce slots数量是4,我设置reduce数量成8的时候,每个reduce执行的很快,shuffle过程也短,最终job完成时间差不多是7分钟,而设置为2时,shuffle时间很长,job完成时间为12分钟.当我再设置为4个reduce task时, 执行时间差不多8分钟

后来我又做了三个长时间job并发运行的测试,结果显示纵使有很多个map slot在运行, 两台slaves的CPU与内存利用率不是很离谱, 但不同的场景应该有不同的设置,主要还是根据slave的负载来决定. 查看slave机器的负载可使用top命令
*********************************

[color=orange]橙色[/color]： 正常的调优点，试验后有正常的反应
[color=red]红色[/color]： 不可理喻的地方，与正常的想法相违背
[color=yellow]黄色[/color]： 可有可无的地方，只是试验了，不推荐使用

调优是基于Hadoop 0.21版本。不再过多解释了，看过后如有不认同且有争议的调优点，请与我讨论，谢谢