mapreduce性能测试
- 作者: 我是坏人8190
- 来源: 51数据库
- 2020-10-05
1) 优化map,reduce任务运行的数量
症状：
每个 map 或 reduce 任务都在30-40秒内结束。一个大job没有使用上所有集群中的可用槽位。在大部分mapper和reducer都订好运行计划后，1到2个仍在pending状态直到最后才单独运行。 诊断:优化map和reduce的任务是非常重要但是经常被忽视，这里介绍几个我常用的相关设置方法：
如果每个任务只执行30-40秒就结束，请减少总的task数量。Task的基本设置和计划本身会消耗几秒钟的时间。所以如果Task执行非常快的话，时间就都浪费在准备Task上了。也可以开启JVM的reuse功能来减少建立task的基本开销。如果job要处理超过1TB的数据，可以考虑增加输入数据的块Block的大小从256MB到512MB。这样也会减小需要运行的Task数。可以通过如下命令改变数据块大小：hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks.执行完该命令就可以清除原来的文件了。在保证每个任务执行都超过30-40秒后，可以增加mapper task为mapper slot(可以执行mapper 机器)的整数倍，如果你有100个可以运行Map任务的节点，尽量不要运行101个Map Task，第101个Map task 会在第一批100个Map任务执行完之后才执行，这点主要针对的是小型集群和小型任务。
不要计划执行太多的Reduce任务，对于大多数任务，我们建议Reduce任务数要等于或小于集群中可运行Reduce任务的节点数。
性能测试:
我使用一个参数-Dmapred.max.split.size=$[16*1024*1024] 来展示设置了过多任务的wordcount程序。这样会产生2640个而不是默认的360个任务来执行该程序。当以这种配置运行时单个的任务平均只用9秒，在JobTracker的监控页面上可以看到正在map任务数在0到24之间波动，整个Job花了17分52秒，是原来配置的2倍。
2) 在集群上使用 LZO 压缩插件
症状：
*应用于中间数据LZO压缩始终是个好方法。
*MapReduce 任务输出文件尺寸很大。
*在任务运行时Slave节点上top和iostat中显示高iowait。
诊断：
几乎任何产生大量map输出的MapReduce任务都能从LZO压缩算法受益。虽然LZO增加了一些CPU的负载，但是shuffle阶段减少的大量磁盘IO操作会把时间完全节省回来。
当job要处理大量数据时，LZO压缩也可以增加输出方面的的性能。在默认的3份复制配置下，每1GB压缩省下的空间都相当于节省了3GB的IO写操作。
要开启LZO压缩，请见另一篇文章，
记得要把mapred.compress.map.output设为true。
性能对比:
禁用LZO只在测试中轻微延长了运行时间。但是文件写出量计数FILE_BYTESwww.hbbz08.com_WRITTEN从3.5G增长到9.2G，显示出62%的IO优化效果，在一个job独自运行的环境下，IO并不是瓶颈，所以时间缩短并不明显。当在高任务并发的集群上运行时，60%的IO减少会带来明显的速度提升。
3) 正确配置Hadoop集群
症状：
*当所有的MapReduce任务栏位都在运行任务时，用top命令观察到slave节点仍然相对的空闲。
*用top观察到内核进程RAID(mdX_raid*)或pdflush占用大量CPU
*Linux平均负载经常高于系统CPU数x2
*执行任务时，Linux平均负载低于系统CPU数
*节点上超过几MB的SWAP使用量
诊断：
症状：
每个 map 或 reduce 任务都在30-40秒内结束。一个大job没有使用上所有集群中的可用槽位。在大部分mapper和reducer都订好运行计划后，1到2个仍在pending状态直到最后才单独运行。 诊断:优化map和reduce的任务是非常重要但是经常被忽视，这里介绍几个我常用的相关设置方法：
如果每个任务只执行30-40秒就结束，请减少总的task数量。Task的基本设置和计划本身会消耗几秒钟的时间。所以如果Task执行非常快的话，时间就都浪费在准备Task上了。也可以开启JVM的reuse功能来减少建立task的基本开销。如果job要处理超过1TB的数据，可以考虑增加输入数据的块Block的大小从256MB到512MB。这样也会减小需要运行的Task数。可以通过如下命令改变数据块大小：hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks.执行完该命令就可以清除原来的文件了。在保证每个任务执行都超过30-40秒后，可以增加mapper task为mapper slot(可以执行mapper 机器)的整数倍，如果你有100个可以运行Map任务的节点，尽量不要运行101个Map Task，第101个Map task 会在第一批100个Map任务执行完之后才执行，这点主要针对的是小型集群和小型任务。
不要计划执行太多的Reduce任务，对于大多数任务，我们建议Reduce任务数要等于或小于集群中可运行Reduce任务的节点数。
性能测试:
我使用一个参数-Dmapred.max.split.size=$[16*1024*1024] 来展示设置了过多任务的wordcount程序。这样会产生2640个而不是默认的360个任务来执行该程序。当以这种配置运行时单个的任务平均只用9秒，在JobTracker的监控页面上可以看到正在map任务数在0到24之间波动，整个Job花了17分52秒，是原来配置的2倍。
2) 在集群上使用 LZO 压缩插件
症状：
*应用于中间数据LZO压缩始终是个好方法。
*MapReduce 任务输出文件尺寸很大。
*在任务运行时Slave节点上top和iostat中显示高iowait。
诊断：
几乎任何产生大量map输出的MapReduce任务都能从LZO压缩算法受益。虽然LZO增加了一些CPU的负载，但是shuffle阶段减少的大量磁盘IO操作会把时间完全节省回来。
当job要处理大量数据时，LZO压缩也可以增加输出方面的的性能。在默认的3份复制配置下，每1GB压缩省下的空间都相当于节省了3GB的IO写操作。
要开启LZO压缩，请见另一篇文章，
记得要把mapred.compress.map.output设为true。
性能对比:
禁用LZO只在测试中轻微延长了运行时间。但是文件写出量计数FILE_BYTESwww.hbbz08.com_WRITTEN从3.5G增长到9.2G，显示出62%的IO优化效果，在一个job独自运行的环境下，IO并不是瓶颈，所以时间缩短并不明显。当在高任务并发的集群上运行时，60%的IO减少会带来明显的速度提升。
3) 正确配置Hadoop集群
症状：
*当所有的MapReduce任务栏位都在运行任务时，用top命令观察到slave节点仍然相对的空闲。
*用top观察到内核进程RAID(mdX_raid*)或pdflush占用大量CPU
*Linux平均负载经常高于系统CPU数x2
*执行任务时，Linux平均负载低于系统CPU数
*节点上超过几MB的SWAP使用量
诊断：
推荐阅读
