MapReduce:Job性能调优总结

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

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



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

reduce task的数量由client来设置
我测试的结果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命令
*********************************

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

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

评论

3 楼 JimmyLincole 2013-11-06  

pdf文件最后一页，有这样的一句话：“首先想要让所有merge都在内存中执行, 就要开启这种memtomem的模式
mapreduce.reduce.merge.memtomem.enabled, 不然所有merge结果最后都得到内存呆着”


请问，红色着重的“内存”是否应该为磁盘？？？谢谢

2 楼 JimmyLincole 2013-11-06  

好东西

1 楼 wupuyuan 2012-04-06  

先看看，我以后去IBM接触的是Commerce  和 J9 估计和hadoop还是接触机会不多。打算好好看看J9.