我怀疑这可能是AWS最终的内部问题，但是由于我目前没有Premium AWS支持（更新：已签署）支持AWS，希望我能从他们那里得到答案）。
我有一个重复的EMR工作，我最近从使用cc2.8xlarge服务器切换到c3.8xlarge服务器。在我第一次运行新配置时，我的一个map-reduce工作通常需要2-3分钟才会花费超过9小时将数据从映射器复制到唯一的reducer。我在9.5小时后杀了这个工作，重新开始在一个新的EMR集群上开始工作，我在第一个小时看到了同样的行为，所以再次杀了它。当我将我的工作改回使用cc2.8xlarge服务器时，工作在2-3分钟内完成。
我检查了AWS的健康仪表板，但没有出现任何错误。 c2.8xlarge服务器在cc2.8xlarge上的所有帐户上应该相同或更快（更多CPU，使用SSD等）。看起来所有群集都在us-east-1a上。
有没有人遇到过类似的问题？关于如何进一步调试的任何想法？
答案 0 :(得分：1)
c3.8large和cc2.8xlarge之间存在2个可能导致问题的区别：
如果您使用Hadoop 2.0，请检查here以进行验证;如果您使用Hadoop 1.0，请检查here
如果您在提供的链接中看到使用Hadoop 1.0，则对于c3.8xlarge实例，映射器和缩减器的数量（默认情况下）要高得多（默认情况下）。这意味着为每个map和reduce任务分配的内存更少（因为两个实例类型的内存大致相同）
您描述问题的方式听起来就像您的工作内存不足，因此开始使用磁盘。这可以从我上面列出的第二个问题中解释。
@ Dolan Antenucci：*现在关于m1.xlarge vs m3.xlarge问题，我们在一些 I / O-bound emr作业中也遇到了同样的问题。我们得出的结论是，其背后的原因是m3.xlarge实例的磁盘空间比m1.xlarge（小于1.6 TB）小得多。因此，在我们的案例中，我们得到的错误是“＃34;空间错误＆＃34;某种。 检查您是否也得到相同类型的错误可能对您有用。
答案 1 :(得分：1)
更新有点晚，但我确实收到了来自AWS Support的回复。这个问题与他们在新AMI版本中修复的错误有关。
警告： 我正在使用Boto AMI = 'latest'，但这实际上并没有给我最新版本。它不是使用AMI v3.3.0（截至2015年10月的最新版本），而是使用AMI v2.4.2。
以下是AWS Support的完整回复，描述了错误和修复：
对不起，我很抱歉。我能够看看所有3个集群 你提供的。我可以看到重复的“太多的获取失败” 步错误日志。
原因是多个reducer试图从单个中获取 tasktracker用于地图输出，无法检索输出并最终 每个映射尝试任务失败，提取失败错误太多。 Hadoop通过在另一个tasktracker上重新安排地图来恢复。可能会导致 如果在tasktracker上执行了许多映射，则会延迟处理 有麻烦提供输出。
我可以看到你已经指定了AMI版本2.4.2，其中就是这样 被称为码头虫：
https://issues.apache.org/jira/browse/MAPREDUCE-2980
我们知道这个问题的发生是间歇性的。
根据这个链接：
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/ami-versions-supported.html
超过2.4.5的AMI版本包含针对此错误的修复程序。
我建议升级到我们最新的AMI版本 - 2.4.8以备将来使用 应该解决这个问题的工作。
s3-dist-cp作业失败的m1.xlarge服务器）的解决方案： 问题是我根本没有足够的DFS空间来完成我的s3-dist-cp工作。我切换到具有更多存储空间的服务器类型，并且工作完成没有问题。
以下是AWS支持的完整回复：
在审核失败的群集时，我可以看到以下重复内容 失败的reduce任务尝试：
2014-10-20 13：00：21,489 WARN org.apache.hadoop.hdfs.DFSClient （DataStreamer for file 的/ tmp / 51d16df5-4acd-42ca-86c8-ba21960b7567 / TEMPSPACE / 45e2055a-f3f7-40a1-b36f-91deabb5db511ca8b8e3-a3a2-417f-b3da-ff17b4bd4af8）： DataStreamer异常：org.apache.hadoop.ipc.RemoteException： java.io.IOException：文件 的/ tmp / 51d16df5-4acd-42ca-86c8-ba21960b7567 / TEMPSPACE / 45e2055a-f3f7-40a1-b36f-91deabb5db511ca8b8e3-a3a2-417f-b3da-ff17b4bd4af8 只能复制到0个节点，而不是1个 org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock（FSNamesystem.java:1569） ...
检查主节点上的实例状态日志，我也发现了 每个数据节点上的HDFS使用率非常高。 DFS已使用％ 7个数据节点中有5个超过90％。
如果你看一下这个文件：
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/UsingEMR_s3distcp.html
＆＃34;在复制操作期间，S3DistCp会暂存一份临时副本 集群中的HDFS输出。必须有足够的自由空间 HDFS用于暂存数据，否则复制操作失败。在 另外，如果S3DistCp失败，它不会清除临时HDFS 因此，您必须手动清除临时文件。对于 例如，如果将500 GB的数据从HDFS复制到S3，则S3DistCp将复制 整个500 GB进入HDFS的临时目录，然后上传了 从临时目录到Amazon S3的数据。当副本是 完成后，S3DistCp将从临时目录中删除文件。如果 在复制之前，你只有250 GB的空间留在HDFS中 复制操作失败。＆＃34;
因此，HDFS文件系统空间不足似乎是导致这种情况的原因 问题。为确保S3distCP能够成功运行，请确保 剩下至少50％的HDFS空间。否则，如果副本是 不成功的临时文件也将占用HDFS空间 不能自动清理。