我在1.1gb文件上多次运行hadoop mapreduce，使用不同数量的Map器和还原器（例如，1个Map器和1个还原器，1个Map器和2个还原器，1个Map器和4个还原器，…）
hadoop安装在具有超线程的四核机器上。
以下是按最短执行时间排序的前5个结果：
+----------+----------+----------+
| time | # of map | # of red |
+----------+----------+----------+
| 7m 50s | 8 | 2 |
| 8m 13s | 8 | 4 |
| 8m 16s | 8 | 8 |
| 8m 28s | 4 | 8 |
| 8m 37s | 4 | 4 |
+----------+----------+----------+编辑
对于1-8个reducer和1-8个mapper的结果：column=#of mappers row=#of reducer
+---------+---------+---------+---------+---------+
| | 1 | 2 | 4 | 8 |
+---------+---------+---------+---------+---------+
| 1 | 16:23 | 13:17 | 11:27 | 10:19 |
+---------+---------+---------+---------+---------+
| 2 | 13:56 | 10:24 | 08:41 | 07:52 |
+---------+---------+---------+---------+---------+
| 4 | 14:12 | 10:21 | 08:37 | 08:13 |
+---------+---------+---------+---------+---------+
| 8 | 14:09 | 09:46 | 08:28 | 08:16 |
+---------+---------+---------+---------+---------+（1） 当我有8个Map器时，程序看起来运行得稍微快一点，但是为什么当我增加还原器的数量时它会慢下来呢(e、 g.8减速器/2减速器比8减速器/8减速器快）
（2） 当我只使用4个Map器时，速度会慢一些，因为我没有使用其他4个核心，对吗？
2条答案
按热度按时间ipakzgxi1#
引用“hadoop明确指南，第3版”，第306页
因为mapreduce作业通常是i/o绑定的，所以有必要使用比处理器更多的任务来获得更好的利用率。
超额订阅的数量取决于您运行的作业的cpu利用率，但一个好的经验法则是比处理器多出一到两个任务（同时计算map和reduce任务）。
上面引用的处理器相当于一个逻辑核。
但这只是理论上的，很可能每个用例都不同于另一个，比如niels的详细解释，一些测试需要执行。
k2arahey2#
Map器和还原器的最佳数量与许多事情有关。
主要的目标是在所使用的cpu功率、传输的数据量（在mapper中、在mapper和reducer之间以及在reducer之外）和磁盘“磁头移动”之间取得平衡。
如果mapreduce作业中的每个任务都能“以最小的磁头移动”读/写数据，那么它的工作效果最好。通常被描述为“顺序读/写”。但是如果任务是cpu绑定的，额外的磁盘头移动不会影响作业。
在我看来，在这种特殊情况下
一个Map器，它需要相当多的cpu周期（也就是说，更多的Map器使它运行得更快，因为cpu是瓶颈，磁盘可以跟上提供输入数据的速度）。
一种几乎不占用cpu周期且主要受io限制的减速机。这导致使用一个减速机时，您仍然受到cpu的限制，而使用4个或更多减速机时，您似乎受到io的限制。所以4个异径管会导致磁头移动过多。
处理这种情况的可能方法：
首先，完全按照您所做的做：进行一些测试运行，看看在给定特定作业和特定集群的情况下哪个设置的性能最好。
那么你有三个选择：
接受你现在的处境
将负载从cpu转移到磁盘或其他方式。
获得更大的集群：更多的cpu和/或更多的磁盘。
转移负载的建议：
如果cpu受限且所有cpu都已满负荷，则减少cpu负荷：
检查代码中不必要的cpu周期。
切换到“较低cpu影响”的压缩编解码器：即从gzip转到snappy或“无压缩”。
调整工作中Map器/还原器的数量。
如果io已绑定，并且您还有一些cpu容量：
启用压缩：这会使CPU工作更努力，并减少磁盘必须做的工作。
尝试各种压缩编解码器（我建议坚持使用snapy或gzip。。。我经常和gzip一起去。
调整工作中Map器/还原器的数量。