我怀疑这可能是一个内部的东西在aws的结束，但我在这里张贴，因为我没有高级的aws支持目前（更新：注册了aws支持，所以希望我可以得到一个答案从他们）。
我有一个经常性的电子病历工作，我最近从使用cc2.8XL服务器切换到c3.8XL服务器。在我第一次使用新配置时，我的一个map reduce作业（通常需要2-3分钟）被卡住了，它花费了9个多小时将数据从mappers复制到惟一的reducer。我在9.5小时后终止了作业，在一个新的emr集群上重试启动作业，在第一个小时内看到了相同的行为，所以再次终止了作业。当我将工作切换回使用cc2.8x1大型服务器时，工作在2-3分钟内完成。
我检查了aws的健康 Jmeter 板，但没有显示任何错误。c3.8XL服务器在所有帐户上的速度应与cc2.8XL服务器相同或更快（更多cpu、使用SSD等）。看起来所有的星团都开着 us-east-1a .
有人遇到过类似的问题吗？关于如何进一步调试有什么想法吗？
2条答案
按热度按时间yvgpqqbh1#
我在上面提到了两个问题（在我的评论中是第二个）。以下是我的第一个问题的解决方案（在复制阶段，减速机卡住了）：
更新有点晚，但我确实收到了aws支持人员的回复。这个问题与他们在比我使用的更新的ami版本中修复的一个bug有关。
警告一句：我在用boto
AMI = 'latest'，但这并没有给我最新的版本。它没有使用amiv3.3.0（最新版本为2015年10月），而是使用amiv2.4.2。以下是aws支持部门的完整回复，描述了错误和修复：
很抱歉耽搁了。我可以看看你提供的所有3个集群。我可以在步骤错误日志中看到重复出现的“太多获取失败”。
原因是多个reducer试图从单个tasktracker获取map输出，未能检索输出，最终导致每个map尝试任务失败，并出现太多的获取失败错误。hadoop通过在另一个tasktracker上重新调度map来恢复。如果在tasktracker上执行的多个Map无法提供输出，则可能会导致长时间的处理延迟。
我可以看到您已经指定了ami版本2.4.2，在该版本中这被称为jetty bug：
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 job在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-91deabb5db511ca8b3e3-a3a2-417f-b3da-ff17b4bd4af8）：datastreamer异常：org.apache.hadoop.ipc.remoteexception:java.io.ioexception:file/tmp/51d16df5-4acd-42ca-86c8-ba21960b7567/tempspace/45e2055a-f3f7-40a1-b36f-91deabb5db511ca8b8e3-a3a2-417f-b3da-ff17b4bd4af8只能复制到0个节点，而不是org.apache.hadoop.hdfs.server.namenode.fsnamesystem.getadditionalblock（fsnamesystem）上的1个节点。java:1569) ...
检查主节点上的示例状态日志，我还发现每个数据节点上的hdfs使用率都很高。7个数据节点中有5个节点的dfs使用率高于90%。
如果您查看此文档：
http://docs.aws.amazon.com/elasticmapreduce/latest/developerguide/usingemr_s3distcp.html
在复制操作期间，s3distcp在集群上以hdfs的形式暂存输出的临时副本。hdfs中必须有足够的可用空间来暂存数据，否则复制操作将失败。另外，如果s3distcp失败，它不会清除临时hdfs目录，因此您必须手动清除临时文件。例如，如果将500gb的数据从hdfs复制到s3，s3distcp会将整个500gb复制到hdfs中的临时目录中，然后将数据从临时目录上载到amazons3。复制完成后，s3distcp从临时目录中删除文件。如果在复制之前hdfs中只剩下250 gb的空间，则复制操作将失败。“
因此，hdfs文件系统空间不足似乎是这个问题的原因。为了确保s3distcp能够成功工作，请确保至少还有50%的hdfs空间。否则，如果复制失败，临时文件也将占用hdfs空间，并且不会自动清除。
ncgqoxb02#
c3.8XL和cc2.8XL之间存在两个可能导致问题的差异：
c3.8X大型计算机的磁盘空间要少得多（少2.8 tb）。但我相信这不是你的问题。
c3.8XL为mapreduce任务分配的内存较少（默认配置）。
如果您使用hadoop2.0，请检查此处进行验证；如果您使用hadoop1.0，请检查此处进行验证
在使用hadoop1.0的情况下，正如您在提供的链接中所看到的，对于c3.8x1大型示例，Map器和还原器的数量要高得多（默认情况下）。这意味着在reduce任务中为每个map分配的内存更少（因为两种示例类型的内存大致相同）
您描述问题的方式听起来像是您的作业耗尽了内存，因此开始使用磁盘代替。这可以从我上面列出的第二个问题得到解释。
@dolan antenucci:*现在关于m1.xlarge与m3.xlarge的问题，我们在一些i/o受限的emr作业中也面临同样的问题。我们得出的结论是，这背后的原因是m3.xlarge示例的磁盘空间比m1.xlarge示例小得多（少1.6tb）。所以在我们的例子中，我们得到的错误是某种“空间外错误”。检查是否也得到相同类型的错误对您可能很有用。