我正在测试Amazon EC2 m1.small实例上的MapReduce wordcount示例 我已经关注了亚马逊命令行入门指南。
bin / ec2hadoop launch-cluster test 2
使用此命令我有2个从属节点。 （总共运行3个实例）然后我可以登录到主节点来运行hadoop程序（这是一个捆绑到jar文件中）花了35分钟。
对于可扩展性实验，我使用4个实例运行相同的程序
bin / ec2hadoop launch-cluster test 4
令我惊讶的是，我没有看到任何性能提升。 MapReduce应用程序花费了相同的时间（33分钟）
问题出在哪里？ 是行为可以接受吗？
In mapred-site.xml
mapred.tasktracker.map.tasks.maximum is set to 1
mapred.tasktracker.reduce.tasks.maximum is set to 1
欢迎任何建议。
答案 0 :(得分：0)
根据您的配置，每个节点最多分别有1个map和1个reduce任务。根据您正在运行的作业类型，将这些参数设置为节点上的核心数可能很有用。特别是当map / reduce任务的计算成本很高时。
如果您在评论中说过，减少阶段主导着工作的整体表现，您应该关注这一部分。在Hadoop中，可以在作业的配置中指定作业的reduce任务数，因为它直接影响生成的输出文件的数量。
只有一个reduce任务会给你一个输出文件。 N减少任务将导致N个输出文件。每个文件都包含按键排序的数据。另外，确保减少任务以从地图任务获得给定密钥的所有数据。
简而言之：增加reduce任务的数量可以提高作业的整体性能，但会产生多个输出文件。根据您的需要，这些文件必须在第二个map reduce作业（或Hadoop之外）中按键合并和排序，以确保您获得相同的单个输出文件，就像使用单个reduce任务一样。
答案 1 :(得分：0)
首先，如果正确配置并且随着集群数量的增加，减少器的数量会增加Hadoop应该显示线性可伸缩性
我认为你得到的结果的根本原因是单一减速器。当所有映射器的结果传递给单个reducer时，它会限制簇大小的任何性能提升。如果您将减少器的数量设置为4（按群集中的节点数量），您应该看到增益。
另外 - 我对小实例上的hadoop高效操作有一些疑问。内存接近极限，交换可以启动并消除任何性能。此外 - 这样的实例将获得1GB以太网的很小一部分，它也可能是限制因素。